Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[patch\]\s+NE2000\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[patch\]\s+NE2000\s*$/: 34 ]

Total 34 documents matching your query.

1. Re: [patch] NE2000 (score: 1): Author: Donald Becker <becker@xxxxxxxxx>; Date: Wed, 1 Nov 2000 03:23:38 -0500 (EST); .. If the ne* drivers are going to be updated, you might want to add in the full-duplex support of the latest ne2k-pci.c driver at ftp://www.scyld.com/pub/network/ne2k-pci.c Donald Becker becker@xxxx; /archives/netdev/2000-11/msg00000.html (8,923 bytes)
2. Re: [patch] NE2000 (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>; Date: Wed, 01 Nov 2000 08:27:47 -0500; Ok, here's what I have. Included are your changes, as well as drivers/net/ne.c: * use probe_irq_on/off instead of autoirq_xxx (autoirq is going away) * request_region first thing in ne_probe1, befor; /archives/netdev/2000-11/msg00001.html (45,493 bytes)
3. Re: [patch] NE2000 (score: 1): Author: xxxxxx>; Date: Thu, 02 Nov 2000 03:37:16 -0500; [CC trimmed a bit] Would be nice to get verification from someone with an older (non-PnP) card that this doesn't break the irq detection. Is the game plan to do similar for other drivers before 2.5.x; /archives/netdev/2000-11/msg00005.html (12,554 bytes)
4. Re: [patch] NE2000 (score: 1): Author: xxxxxx>; Date: Thu, 02 Nov 2000 05:19:39 -0500; Have you seen the auto_irq.c code? :) I don't see how it could possibly break, but ya never know... Anyway, to answer your question, yes, Linus has ok'd the elimination of auto_irq.c. It's used in ma; /archives/netdev/2000-11/msg00008.html (13,846 bytes)
5. Re: [patch] NE2000 (score: 1): Author: xxxxxxx; Date: Thu, 2 Nov 2000 19:40:21 -0500 (EST); ... Using dev->name is much more meaningful. I switched over all of my drivers to use dev->name a few years ago. Most people with multiple network adapters use the same board type. Seeing a list of i; /archives/netdev/2000-11/msg00010.html (9,653 bytes)
6. Re: [patch] NE2000 (score: 1): Author: xxxxxx>; Date: Thu, 02 Nov 2000 19:51:37 -0500; You're talking about request_irq not request_region here, and /proc/ioports isn't as "actively useful" as /proc/interrupts. But you do have a point -- It sounds more informative to have dev->name in; /archives/netdev/2000-11/msg00011.html (9,773 bytes)
7. Re: [patch] NE2000 (score: 1): Author: xxxxxx>; Date: Thu, 02 Nov 2000 21:54:17 -0700; I noticed while writing some hashed device lookup-by-name code that names can be changed at run time. Would that affect the decision any? -- Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatec; /archives/netdev/2000-11/msg00012.html (9,820 bytes)
8. Re: [patch] NE2000 (score: 1): Author: xxxxxx>; Date: Sat, 4 Nov 2000 14:01:24 +0000 (GMT); [snip discussion about removing PCI code from ne.c] I'd thought it was quite important to get drivers doing ioremap() properly before 2.4.0, since the whinging messages along the lines of "io mapaddr; /archives/netdev/2000-11/msg00013.html (9,821 bytes)
9. Re: [patch] NE2000 (score: 1): Author: xxxxxx>; Date: Mon, 06 Nov 2000 01:37:31 -0500; The ioremap patch I did for 8390 based cards was circa Dec 1999, and the impression I got at the time was that the isa_xxx stuff was good enough for 2.4.0 - the cleanup could wait until 2.5.x - and s; /archives/netdev/2000-11/msg00021.html (10,127 bytes)
10. Re: [patch] NE2000 (score: 1): Author: xxxxxx>; Date: Mon, 06 Nov 2000 04:57:55 -0500; I think isa_ioremap is good enough for 2.4.x... If the driver works, I don't want to touch it. But if you are in there touching the code anyway, and doing testing anyway, you might as well fix it to; /archives/netdev/2000-11/msg00024.html (10,520 bytes)
11. Re: [patch] NE2000 (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>; Date: Sun, 29 Oct 2000 15:08:45 -0500; /archives/netdev/2000-10/msg00131.html (8,620 bytes)
12. Re: [patch] NE2000 (score: 1): Author: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>; Date: Sun, 29 Oct 2000 20:34:06 +0000 (GMT); /archives/netdev/2000-10/msg00132.html (7,969 bytes)
13. Re: [patch] NE2000 (score: 1): Author: Paul Gortmaker <p_gortmaker@xxxxxxxxx>; Date: Mon, 30 Oct 2000 04:17:42 -0500; /archives/netdev/2000-10/msg00134.html (9,270 bytes)
14. Re: [patch] NE2000 (score: 1): Author: pavel rabel <pavel@xxxxxxxxxxx>; Date: Mon, 30 Oct 2000 15:58:33 +0100 (CET); /archives/netdev/2000-10/msg00135.html (8,082 bytes)
15. Re: [patch] NE2000 (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>; Date: Mon, 30 Oct 2000 14:29:27 -0500; /archives/netdev/2000-10/msg00136.html (22,964 bytes)
16. Re: [patch] NE2000 (score: 1): Author: Jorge Nerin <comandante@xxxxxxxxxxxxx>; Date: Mon, 30 Oct 2000 11:57:55 +0100; /archives/netdev/2000-10/msg00137.html (8,760 bytes)
17. Re: [patch] NE2000 (score: 1): Author: Paul Gortmaker <p_gortmaker@xxxxxxxxx>; Date: Wed, 01 Nov 2000 00:31:00 -0500; /archives/netdev/2000-10/msg00146.html (19,914 bytes)
18. Re: [patch] NE2000 (score: 1): Author: Donald Becker <becker@xxxxxxxxx>; Date: Wed, 1 Nov 2000 03:23:38 -0500 (EST); .. If the ne* drivers are going to be updated, you might want to add in the full-duplex support of the latest ne2k-pci.c driver at ftp://www.scyld.com/pub/network/ne2k-pci.c Donald Becker becker@xxxx; /archives/netdev/2000-11/msg00134.html (9,006 bytes)
19. Re: [patch] NE2000 (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>; Date: Wed, 01 Nov 2000 08:27:47 -0500; Paul, Ok, here's what I have. Included are your changes, as well as drivers/net/ne.c: * use probe_irq_on/off instead of autoirq_xxx (autoirq is going away) * request_region first thing in ne_probe1,; /archives/netdev/2000-11/msg00135.html (45,810 bytes)
20. Re: [patch] NE2000 (score: 1): Author: Paul Gortmaker <p_gortmaker@xxxxxxxxx>; Date: Thu, 02 Nov 2000 03:37:16 -0500; [CC trimmed a bit] Would be nice to get verification from someone with an older (non-PnP) card that this doesn't break the irq detection. Is the game plan to do similar for other drivers before 2.5.x; /archives/netdev/2000-11/msg00139.html (12,866 bytes)

Current List: 1 - 20
Page: [1] [2]