[ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Jeff Garzik]

(GregKH cc'd for his deprecated list)

Though this has already been mentioned, I thought I would send out a 
reminder.  The following net drivers are slated for removal "soon", in 
the next kernel version or so:


1) iphase (iph5526 a.k.a. drivers/net/fc/*)

Been broken since 2.3 or 2.4.  Only janitors have kept it compiling.


2) xircom_tulip_cb

Unmaintained, and does not work for all xircom 32bit cards.  xircom_cb, 
on the other hand, works for ALL xircom 32bit cards.


3) eepro100

Unmaintained; users should use e100.

When I last mentioned eepro100 was going away, I got a few private 
emails saying complaining about issues not yet taken care of in e100. 
eepro100 will not be removed until these issues are resolved.

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Christoph Hellwig]

On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> 1) iphase (iph5526 a.k.a. drivers/net/fc/*)
> 
> Been broken since 2.3 or 2.4.  Only janitors have kept it compiling.

No, it doesn't even compile, and didn't so for more than two years.

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Russell King]

On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> 3) eepro100
> 
> Unmaintained; users should use e100.
> 
> When I last mentioned eepro100 was going away, I got a few private 
> emails saying complaining about issues not yet taken care of in e100. 
> eepro100 will not be removed until these issues are resolved.

Has e100 actually been fixed to use the PCI DMA API correctly yet?
Looking at it, it doesn't look like it, so until it does, eepro100
is the far better bet for platforms needing working DMA API.

What I'm talking about is e100's apparant belief that it can modify
rfd's in the receive ring on a non-cache coherent architecture and
expect the data around it to remain unaffected (see e100_rx_alloc_skb):

struct rfd {
        u16 status;
        u16 command;
        u32 link;
        u32 rbd;
        u16 actual_size;
        u16 size;
};

it touches command and link.  This means that the whole rfd plus
maybe the following or preceding 16 bytes get loaded into a cache
line (assuming cache lines of 32 bytes), and that data written
out again at sync.  However, it does this on what seems to be an
active receive chain.

So, both the CPU _and_ the device own the same data.  Which is a
violation of the DMA API.

So, eepro100 works.  e100 is a dead loss for non-cache coherent
architectures.  Therefore, I say eepro100 stays until e100 is
fixed.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[David S. Miller]

On Thu, 27 Jan 2005 22:57:25 +0000
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> Has e100 actually been fixed to use the PCI DMA API correctly yet?

It seems to be doing the right thing.  I see the DMA sync calls
(properly using cpu vs. device syncing variants) at the right
spots, and the only thing the chip really relies upon is ordering
of visibility and this is achieved via a combination of cpu memory
barriers and the correct DMA sync calls.

For example, a pci_dma_sync_single_for_cpu() is always performed before
peeking at the descriptors at RX interrupt time (see e100_rx_indicate).

When new descriptors are written to, then linked into the chain it
memory barriers the cpu writes then DMA syncs the previous descriptor
to the device.  This is occuring in e100_alloc_skb().

Therefore the only missing sync would be of the new RX descriptor
when linking things in like that, ie. at the end of e100_rx_alloc_skb()
if rx->prev->skb is non-NULL.

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Russell King]

On Thu, Jan 27, 2005 at 03:31:14PM -0800, David S. Miller wrote:
> Therefore the only missing sync would be of the new RX descriptor
> when linking things in like that, ie. at the end of e100_rx_alloc_skb()
> if rx->prev->skb is non-NULL.

And that is inherently unsafe, since the chip may be modifying the RFD
while the CPU is accessing it.  Adding extra sync calls does not fix
it because as far as I can see, there's nothing to tell the chip "don't
write to this RFD because any changes the CPU is making right now will
overwrite the chips own changes."

The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
There's a message from me back on 30th June 2004 at about 10:30 BST on
this very list which generated almost no interest from anyone...

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Lennert Buytenhek]

On Fri, Jan 28, 2005 at 12:14:30AM +0000, Russell King wrote:

> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.

Hmmm, I recall e100 working fine on a Radisys ENP-2611, which has a
IXP2400 (xscale) in big-endian mode, running 2.6.  This particular
board had its root fs NFS-mounted and pumped several hundreds of
gigabytes through the NIC during a period of at least a few months,
and I never saw any problems.

Something tells me that the next time I try it, it won't work at all.


--L

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[David S. Miller]

On Fri, 28 Jan 2005 00:14:30 +0000
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
> There's a message from me back on 30th June 2004 at about 10:30 BST on
> this very list which generated almost no interest from anyone...

I see.  Since eepro100 just uses a fixed set of RX buffers in the
ring (ie. the DMA links are never changed) it works.

This adapter was definitely developed for a system that has to have
PCI device DMA and CPU cached data accesses in the same coherency
space in order to use their weird RX chaining thing.

So essentially, e100 needs to have it's RX logic rewritten so that
it uses a static RX descriptor set of buffers and skb_copy()'s them
to push the packets into the stack.

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Scott Feldman]

On Thu, 2005-01-27 at 16:48, David S. Miller wrote:
> On Fri, 28 Jan 2005 00:14:30 +0000
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> 
> > The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
> > There's a message from me back on 30th June 2004 at about 10:30 BST on
> > this very list which generated almost no interest from anyone...
> 
> I see.  Since eepro100 just uses a fixed set of RX buffers in the
> ring (ie. the DMA links are never changed) it works.

eepro100 does a copy if pkt_len < rx_copybreak, otherwise it send up the
skb and allocates and links a new one in it's place (see
speedo_rx_link).

So I would say e100 and eepro100 are the same for >= rx_copybreak.  Why
does one work and not the other?  Is it because the RFD is aligned in
eepro100?

Russell, what happens with modprobe eepro100 rx_copybreak=0?

-scott

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[David S. Miller]

On Thu, 27 Jan 2005 17:58:37 -0800
Scott Feldman <sfeldma@pobox.com> wrote:

> eepro100 does a copy if pkt_len < rx_copybreak, otherwise it send up the
> skb and allocates and links a new one in it's place (see
> speedo_rx_link).

My bad, you're right.  So I wonder too what the difference
is that makes it work on ARM et al.

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Greg KH]

On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> 
> (GregKH cc'd for his deprecated list)

It's a file in the Documentation/ directory, feel free to just patch it,
adding entries for these drivers.

thanks,

greg k-h

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Jason Lunz]

["Followup-To:" header set to gmane.linux.kernel.]
jgarzik@pobox.com said:
> 3) eepro100
>
> Unmaintained; users should use e100.
>
> When I last mentioned eepro100 was going away, I got a few private 
> emails saying complaining about issues not yet taken care of in e100. 
> eepro100 will not be removed until these issues are resolved.

I have an intel eepro100 card in an old PII 266. With eepro100, it gets
~9Mbit, but e100 struggles to keep its head above 1Mbit, and is very
erratic.

Also, drivers/net/Kconfig still claims that E100_NAPI exists, but the
option to disable napi has long since been removed from the driver.

Jason

--- linux-2.6.10/drivers/net/Kconfig.pre	2005-01-29 15:40:48.000000000 -0500
+++ linux-2.6.10/drivers/net/Kconfig	2005-01-29 15:41:01.000000000 -0500
@@ -1435,23 +1435,6 @@
 	  <file:Documentation/networking/net-modules.txt>.  The module
 	  will be called e100.
 
-config E100_NAPI
-	bool "Use Rx Polling (NAPI)"
-	depends on E100
-	help
-	  NAPI is a new driver API designed to reduce CPU and interrupt load
-	  when the driver is receiving lots of packets from the card. It is
-	  still somewhat experimental and thus not yet enabled by default.
-
-	  If your estimated Rx load is 10kpps or more, or if the card will be
-	  deployed on potentially unfriendly networks (e.g. in a firewall),
-	  then say Y here.
-
-	  See <file:Documentation/networking/NAPI_HOWTO.txt> for more
-	  information.
-
-	  If in doubt, say N.
-
 config LNE390
 	tristate "Mylex EISA LNE390A/B support (EXPERIMENTAL)"
 	depends on NET_PCI && EISA && EXPERIMENTAL

[2.6 patch] kill IPHASE5526

[Adrian Bunk]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On Thu, Jan 27, 2005 at 09:07:31PM +0000, Christoph Hellwig wrote:
> On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> > 1) iphase (iph5526 a.k.a. drivers/net/fc/*)
> > 
> > Been broken since 2.3 or 2.4.  Only janitors have kept it compiling.
> 
> No, it doesn't even compile, and didn't so for more than two years.

A patch to remove it is attached.


<--  snip  -->


iph5526 does no longer compile since 2.5 wand was therefore marked as 
broken. This patch removes it.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/net/Kconfig             |    9 
 drivers/net/Makefile            |    1 
 drivers/net/fc/Makefile         |    8 
 drivers/net/fc/iph5526.c        | 4645 --------------------------------
 drivers/net/fc/iph5526_ip.h     |   24 
 drivers/net/fc/iph5526_novram.c |  278 -
 drivers/net/fc/iph5526_scsi.h   |   31 
 drivers/net/fc/tach.h           |  475 ---
 drivers/net/fc/tach_structs.h   |  428 --
 9 files changed, 5899 deletions(-)


[-- Attachment #2: patch-remove-iphase.gz --]
[-- Type: application/octet-stream, Size: 43176 bytes --]