From: Tomasz Chmielewski <hidden> Date: 2007-05-08 08:30:26
Michael Jones wrote:
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?
--
Tomasz Chmielewski
http://wpkg.org
On 5/8/07, Tomasz Chmielewski [off-list ref] wrote:
Michael Jones wrote:
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".
I was always curious, why do people want to run ixp4xx in LE mode? What
are the benefits that overweight the obvious performance degradation?
From: Tomasz Chmielewski <hidden> Date: 2007-05-08 08:56:36
Alexey Zaytsev schrieb:
On 5/8/07, Tomasz Chmielewski [off-list ref] wrote:
quoted
Michael Jones wrote:
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".
I was always curious, why do people want to run ixp4xx in LE mode? What
are the benefits that overweight the obvious performance degradation?
I guess the main reason, at least for me, is that there is only one
distro that properly supports LE ARM: Debian.
It greatly simplifies management/administration of a higher number of
devices, given the fact that Debian also supports other architectures
(not just x86/64, sometimes PPC, like most distros do).
Not always network performance is to most important factor.
--
Tomasz Chmielewski
http://wpkg.org
And also out-of-kernel drivers for things like webcams, which have been
naively written for x86 little endian and have no concept of endian
neutrality. In some cases it's just easier to run LE instead of
fighting with the driver code.
BTW, for the consumer-level IXP42x devices (like the NSLU2) the
performance difference is *completely* overwhelmed by slowness in the
rest of the system.
-- Rod
From: Christoph Hellwig <hch@infradead.org> Date: 2007-05-16 07:13:19
On Tue, May 08, 2007 at 10:29:03AM +0200, Tomasz Chmielewski wrote:
Michael Jones wrote:
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.
From: Michael-Luke Jones <hidden> Date: 2007-05-16 07:35:22
On 16 May 2007, at 08:13, Christoph Hellwig wrote:
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.
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.
From: Michael-Luke Jones <hidden> Date: 2007-05-16 10:20:29
On 16 May 2007, at 10:41, Lennert Buytenhek wrote:
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.
While this comment is technically correct, Christian's driver
achieves endian agnostic operation with only 10 additional lines of
code [1].
Thus, there is no reason to assume that gaining LE support will be a
major issue.
Michael-Luke
[1] http://www.hohnstaedt.de/ixp_npe/0.3.1/ixp4xx_npe_driver-0.3.1.diff
Search in this file for "swap the payload of the SKB" (it's in
mac_driver.c)
From: Rod Whitby <hidden> Date: 2007-05-16 10:48:38
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
On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote:
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.
The NSLU2 people are the ones here that are saying that the driver
should really support LE (because that is what they happen to be
using, the rest of the world runs the ixp4xx in BE), and they keep
saying that it would be so easy to make a patch to add LE support,
but so far they haven't produced such a patch.
Please just write the patch and let's get this over with.
From: Rod Whitby <hidden> Date: 2007-05-16 11:37:19
Lennert Buytenhek wrote:
On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote:
quoted
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.
The NSLU2 people are the ones here that are saying that the driver
should really support LE (because that is what they happen to be
using, the rest of the world runs the ixp4xx in BE)
I'll repeat again. NSLU2-Linux supports both BE and LE. We have about
5,000 users running BE and about 5,000 users running LE. Perhaps you're
confusing the NSLU2-Linux project (which official supports both endians
equally) with the Debian project (which official supports only LE, and
has an unofficial BE port).
One NSLU2-Linux person said they would prefer the driver to support LE,
but would be happy for it to be marked BE only in the Kconfig as an
alternative. That is consistent with what I wrote in my message.
Please just write the patch and let's get this over with.
Please let's just stop arguing about it. If a patch appears before it
gets merged, then great. If it doesn't then it will appear at a later date.
-- Rod
On Wed, May 16, 2007 at 09:05:18PM +0930, Rod Whitby wrote:
quoted
quoted
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.
The NSLU2 people are the ones here that are saying that the driver
should really support LE (because that is what they happen to be
using, the rest of the world runs the ixp4xx in BE)
I'll repeat again. NSLU2-Linux supports both BE and LE. We have
about 5,000 users running BE and about 5,000 users running LE.
Perhaps, but somehow I don't think that we'd have seen any reaction
if the submitted driver had only supported LE and not BE.
quoted
Please just write the patch and let's get this over with.
Please let's just stop arguing about it. If a patch appears before
it gets merged, then great. If it doesn't then it will appear at a
later date.