[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <464AE10E.7090606@whitby.id.au>
Date: Wed, 16 May 2007 20:16:38 +0930
From: Rod Whitby <rod@...tby.id.au>
To: Lennert Buytenhek <buytenh@...tstofly.org>
CC: Christoph Hellwig <hch@...radead.org>,
Tomasz Chmielewski <mangoo@...g.org>,
linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.arm.linux.org.uk, netdev@...r.kernel.org,
Michael Jones <mlj28@....ac.uk>,
Krzysztof Halasa <khc@...waw.pl>
Subject: Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lots of people wrote:
> Lots of huffing and puffing about endian support by this driver ...
For what it's worth, the NSLU2-Linux project (which has over 10,000
known users of our custom ixp4xx firmware, most of which will eventually
be users of this new driver) is *endian-neutral*.
We support both big-endian and little-endian usage of the ixp4xx in a
number of consumer devices like the NSLU2, NAS100d, DSMG600, and FSG3.
We are very interested in getting this driver into mainline in the most
expedient and correct fashion acceptable to the relevant mainline
maintainers. We have also discussed this situation with the author of
the previous set of ixp4xx open-source ethernet driver patches, and he
also recommends that we put our support behind this new set of patches.
So, if the author of these patches wishes to concentrate on big-endian
support first, then we will not say (and have not said) anything which
will block inclusion of a big-endian only version of this driver.
In parallel to this initial upstream push, we will be working with the
author to make sure that this driver supports little-endian devices as
well (as we are endian-neutral in our project's support of consumer
devices based on the ixp4xx). If we get this done before upstream
acceptance of the big-endian version, that will be great. If we don't,
then we'll work to hit the next merge window. We will create a
functionally correct little-endian version first (the simple
byte-swapping implementation) and will work on a performance-enhanced
version later (if that is even possible without prohibitive massive
upstream changes).
There simply is no reason for everyone to be arguing about this.
Remember that what we are seeing here is an open-source replacement for
a long-time proprietary driver. We should all rejoice in that, support
the author of these patches, and not fight amongst ourselves.
-- Rod Whitby
-- NSLU2-Linux Project Lead
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists