Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS

On Wed, May 16, 2007 at 08:13:01AM +0100, Christoph Hellwig wrote:

quoted

quoted

quoted

+#ifndef __ARMEB__
+#warning Little endian mode not supported
+#endif

Personally I'm less fussed about WAN / LE support. Anyone with any  
sense will run ixp4xx boards doing such a specialised network  
operation as BE. Also, NSLU2-Linux can't test this functionality with  
our LE setup as we don't have this hardware on-board. You may just  
want to declare a depends on ARMEB in Kconfig (with or without OR  
(ARM || BROKEN) ) and have done with it - it's up to you.

Christian Hohnstaedt's work did support LE though.

Not all ixp4xx boards are by definition "doing such a specialised 
network operation".

Krzysztof, why is LE not supported?

Do you need access to ixp4xx that starts in LE mode?

Not even trying to support LE is a clear merge blocker.  Maybe
Krzysztof can't actually test it himself, which is fine - but
not even pretending to be endian clean is not what proper Linux
drivers do.

The issue is not that the driver is not 'endian clean'.

This is a driver for an on-chip ethernet MAC on an ARM CPU.  I.e. the
ethernet MAC is on the CPU itself, it's not some kind of PCI device or
something like that.  The ARM CPU in question can be run in either
little endian or big endian mode.  Making a driver work in both modes
of operation is generally not just an issue of adding a couple of
be32_to_cpu()s in the right places.

For example, intel IXP2000 and IXP23xx CPU support in arch/arm only
supports big-endian mode of operation, and none of the associated
drivers support little-endian mode.

Most of the other CPU support in arch/arm only supports
little-endian mode, and none of the associated drivers support
big-endian mode.  According to your criterion, that would mean that
most of the ARM drivers (alsa, usb, framebuffer, networking, etc.)
should never have been accepted in the kernel tree in the first place.