Rod Whitby <[EMAIL PROTECTED]> writes:
> 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.
Sure. The "swapping" patch is trivial and I can add it if needed
at some point but I hope we can do that "
Christoph Hellwig <[EMAIL PROTECTED]> writes:
> 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 drivers can only work with IXP4xx CPU an
On Wed, May 16, 2007 at 09:05:18PM +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 NS
Lennert Buytenhek wrote:
> 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 dri
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 th
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 bot
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 onl
On Wed, May 16, 2007 at 08:13:01AM +0100, Christoph Hellwig wrote:
> > >>+#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 netw
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.
w.r.t this comment, a working implemen
On Tue, May 08, 2007 at 10:29:03AM +0200, Tomasz Chmielewski wrote:
> Michael Jones wrote:
>
> >>+#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 sp
On Wed, May 09, 2007 at 03:45:53PM +0100, Michael-Luke Jones wrote:
> No-one is saying that this driver should not be mainlined before it
> has LE support. All that I said was:
>
> > Personally I'd like LE ethernet tested and working before we push.
>
> The alternative would be to explicitly s
On 9 May 2007, at 15:22, David Acker wrote:
Big endian is the natural setup for the NPEs on this hardware
according to the intel documentation. Please don't stop this
driver from moving forward so that a few folks can run their
hardware in slow mode.
No-one is saying that this driver shou
Lennert Buytenhek wrote:
The people who need a LE network driver can use Christian's driver,
as Christian's driver works in LE just fine. The people who care
about LE support can add LE support to the driver that Krzysztof wrote.
I don't think that not supporting LE is a reason not to merge
Krz
On Wed, May 09, 2007 at 12:35:40PM +0200, Mikael Pettersson wrote:
> > > Does that mean that the Debian ARM people have their heads so far
> > > up their collective asses that they think that every form of change
> > > is bad and are unable to accept that some forms of change might be
> > > for th
On Wed, May 09, 2007 at 11:35:03AM +0200, Marcus Better wrote:
> > Does that mean that the Debian ARM people have their heads so far
> > up their collective asses that they think that every form of change
> > is bad and are unable to accept that some forms of change might be
> > for the better?
>
On Wed, 9 May 2007 11:35:03 +0200, Marcus Better wrote:
Lennert Buytenhek wrote:
> Does that mean that the Debian ARM people have their heads so far
> up their collective asses that they think that every form of change
> is bad and are unable to accept that some forms of change might be
> for the
On Wed, 9 May 2007 11:35:03 +0200, Marcus Better wrote:
> Lennert Buytenhek wrote:
> > Does that mean that the Debian ARM people have their heads so far
> > up their collective asses that they think that every form of change
> > is bad and are unable to accept that some forms of change might be
> >
Lennert Buytenhek wrote:
> Does that mean that the Debian ARM people have their heads so far
> up their collective asses that they think that every form of change
> is bad and are unable to accept that some forms of change might be
> for the better?
Well, I am not one of the Debian ARM people, jus
On Wed, May 09, 2007 at 10:58:06AM +0200, Marcus Better wrote:
> >> There _is_ an ARM BE version of Debian.
> >>
> >> It's not an official port, but it's not maintained any worse than
> >> the 'official' LE ARM Debian port is.
>
> > Hmm... That changes a bit. Perhaps we should forget about
> > th
Krzysztof Halasa wrote:
> Lennert Buytenhek <[EMAIL PROTECTED]> writes:
>> There _is_ an ARM BE version of Debian.
>>
>> It's not an official port, but it's not maintained any worse than
>> the 'official' LE ARM Debian port is.
> Hmm... That changes a bit. Perhaps we should forget about
> that LE
Michael-Luke Jones wrote:
> On 8 May 2007, at 09:48, Alexey Zaytsev wrote:
>
>> I was always curious, why do people want to run ixp4xx in LE mode? What
>> are the benefits that overweight the obvious performance degradation?
>
> Debian.
> http://www.debian.org/ports/arm/
And also out-of-kernel d
Tomasz Chmielewski <[EMAIL PROTECTED]> writes:
> Does using ixp4xx on LE have any other drawbacks than inferior network
> performance?
More memory is needed, something like max 600 KB for 2 Ethernet ports.
> And talking about network performance, what numbers are we talking
> about (LE vs BE; 30
Krzysztof Halasa schrieb:
Lennert Buytenhek <[EMAIL PROTECTED]> writes:
There _is_ an ARM BE version of Debian.
It's not an official port, but it's not maintained any worse than
the 'official' LE ARM Debian port is.
Hmm... That changes a bit. Perhaps we should forget about
that LE thing then
Lennert Buytenhek <[EMAIL PROTECTED]> writes:
> There _is_ an ARM BE version of Debian.
>
> It's not an official port, but it's not maintained any worse than
> the 'official' LE ARM Debian port is.
Hmm... That changes a bit. Perhaps we should forget about
that LE thing then, and (at best) put tha
Lennert Buytenhek <[EMAIL PROTECTED]> writes:
> The board support code knows such things as that the "front ethernet
> port" on the board is connected to the CPU's MII port number #2, but
> the board support code does _not_ know that MII port number #2
> corresponds to "ixp4xx hardware queue #5."
Tomasz Chmielewski <[EMAIL PROTECTED]> writes:
> Krzysztof, why is LE not supported?
I'm not yet sure how to do it best.
The trivial way is really trivial, allocate a set of 1536-byte
buffers and make a swap+copy on RX and TX, but I want to
investigate the data-coherent approach first.
> Do you
On Tue, May 08, 2007 at 05:28:21PM +0200, Krzysztof Halasa wrote:
> > I was always curious, why do people want to run ixp4xx in LE mode? What
> > are the benefits that overweight the obvious performance degradation?
>
> Debian is indeed a valid reason.
> I wonder if it would be much work to creat
"Alexey Zaytsev" <[EMAIL PROTECTED]> writes:
> I was always curious, why do people want to run ixp4xx in LE mode? What
> are the benefits that overweight the obvious performance degradation?
Debian is indeed a valid reason.
I wonder if it would be much work to create BE Debian as well.
Simple aut
On Tue, May 08, 2007 at 04:31:12PM +0200, Krzysztof Halasa wrote:
> >> +/* Built-in 10/100 Ethernet MAC interfaces */
> >> +static struct mac_plat_info ixdp425_plat_mac[] = {
> >> + {
> >> + .phy= 0,
> >> + .rxq= 3,
> >> + }, {
> >> + .phy
Lennert Buytenhek <[EMAIL PROTECTED]> writes:
>> +/* Built-in 10/100 Ethernet MAC interfaces */
>> +static struct mac_plat_info ixdp425_plat_mac[] = {
>> +{
>> +.phy= 0,
>> +.rxq= 3,
>> +}, {
>> +.phy= 1,
>> +
Michael-Luke Jones <[EMAIL PROTECTED]> writes:
> Already in mach-ixp4xx, so can just be called npe.c
I want ixp4xx_ prefix in module name, otherwise I'd call it npe.c,
sure.
> Debugging code? Can this go?
Why? Especially with code having to work with third party binary-only
firmware? Suicide. T
On 5/8/07, Alexey Zaytsev <[EMAIL PROTECTED]> wrote:
I was always curious, why do people want to run ixp4xx in LE mode? What
are the benefits that overweight the obvious performance degradation?
Debian on the NSLU2 runs in LE, and it is pretty popular.
http://www.linuxdevices.com/news/NS353532
On Tue, May 08, 2007 at 03:19:22AM +0200, Krzysztof Halasa wrote:
> diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
> b/arch/arm/mach-ixp4xx/ixdp425-setup.c
> index ec4f079..f20d39d 100644
> --- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
> +++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
> @@ -101,10 +10
Alexey Zaytsev schrieb:
On 5/8/07, Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
Michael Jones wrote:
>> +#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
On 8 May 2007, at 09:48, Alexey Zaytsev wrote:
I was always curious, why do people want to run ixp4xx in LE mode?
What
are the benefits that overweight the obvious performance degradation?
Debian.
http://www.debian.org/ports/arm/
Michael-Luke
-
To unsubscribe from this list: send the line
Michael Jones wrote:
+#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
On 5/8/07, Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
Michael Jones wrote:
>> +#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
> op
On Tue, 8 May 2007 08:22:17 +0100, Michael-Luke Jones wrote:
> On 8 May 2007, at 02:19, Krzysztof Halasa wrote:
>
> > Adds a driver for built-in IXP4xx Ethernet MAC and HSS ports
...
> > +#ifndef __ARMEB__
> > +#warning Little endian mode not supported
> > +#endif
>
> This has gone from error to
On 8 May 2007, at 09:26, Mikael Pettersson wrote:
On Tue, 8 May 2007 08:22:17 +0100, Michael-Luke Jones wrote:
AFAIK, it's a HW limitation of the IXP4xx NPEs, or
possibly Intel's microcode for them.
I run my IXP42x boxes big-endian and don't mind doing so.
/Mikael
*cough*
http://www.hohnstae
On 8 May 2007, at 02:19, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx Ethernet MAC and HSS ports
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c b/arch/arm/mach-
ixp4xx/ixdp425-setup.c
index ec4f079..f20d39d 100644
--- a/arch
On 8 May 2007, at 01:36, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx Network Processor Engines.
This patch requires IXP4xx Queue Manager driver and the "fuses" patch.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
[snip]
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_npe.c b/ar
ACK.
I shall presume that the ARM folks will apply these patches. You may
tack on an "Acked-by: Jeff Garzik <[EMAIL PROTECTED]>" onto the ethernet
driver itself.
I'll let the ARM folks review the rest.
I do agree with the comments in the thread that -- as in your most
recent revision -- th
Adds a driver for built-in IXP4xx Network Processor Engines.
This patch requires IXP4xx Queue Manager driver and the "fuses" patch.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
index 71ef55f..25f8994 100644
--- a/arch
Adds a driver for IXP4xx built-in hardware queue manager.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
index 9715ef5..71ef55f 100644
--- a/arch/arm/mach-ixp4xx/Kconfig
+++ b/arch/arm/mach-ixp4xx/Kconfig
@@ -176,6 +176
44 matches
Mail list logo
