[PATCH] ARM: remove ixp2000 platform

[PATCH] ARM: remove ixp2000 platform

[Arnd Bergmann]

On Tuesday 28 February 2012, Rob Herring wrote:
> ixp2000 has no commits other than tree-wide changes or refactoring since
> 2006. No maintainer is listed for ixp2000 either.

I have this in my copy of the MAINTAINERS file:

ARM/INTEL IXP2000 ARM ARCHITECTURE
M:      Lennert Buytenhek <kernel@wantstofly.org>
L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S:      Maintained

It's missing an F: line, otherwise it suggests that the platform is still
maintained by Lennert and it certainly builds just fine. Unfortunately he
seems to have fallen off the edge of the planet at the end of last year.

> If this doesn't fly, my fallback to clean-up io.h is just removing
> CONFIG_IXP2000_SUPPORT_BROKEN_PCI_IO. According to the commit adding it
> (in 2005), it's only needed for pre-production revs which I would guess
> are all but gone by now.

My feeling is that we should keep ixp2000 around but get rid of the
workarounds for preproduction machines. If we can get Lennert to
reply, it should be his decision though.

	Arnd

[PATCH] ARM: remove ixp2000 platform

[Nicolas Pitre]

On Tue, 28 Feb 2012, Arnd Bergmann wrote:

> On Tuesday 28 February 2012, Rob Herring wrote:
> > ixp2000 has no commits other than tree-wide changes or refactoring since
> > 2006. No maintainer is listed for ixp2000 either.
> 
> I have this in my copy of the MAINTAINERS file:
> 
> ARM/INTEL IXP2000 ARM ARCHITECTURE
> M:      Lennert Buytenhek <kernel@wantstofly.org>
> L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S:      Maintained
> 
> It's missing an F: line, otherwise it suggests that the platform is still
> maintained by Lennert and it certainly builds just fine. Unfortunately he
> seems to have fallen off the edge of the planet at the end of last year.

FYI, here's a snippet of a conversation I just had with Lennert on IRC 
today:

13:05 < nico> do you still care about ixp2000?
13:22 < lennert> not really, no
13:58 < nico> do you think we could remove it from the kernel tree?
14:01 < lennert> go for it, and remove ixp23xx too while you're at it


Nicolas

[PATCH] ARM: remove ixp2000 platform

[Rob Herring]

On 03/05/2012 07:41 PM, Nicolas Pitre wrote:
> On Tue, 28 Feb 2012, Arnd Bergmann wrote:
> 
>> On Tuesday 28 February 2012, Rob Herring wrote:
>>> ixp2000 has no commits other than tree-wide changes or refactoring since
>>> 2006. No maintainer is listed for ixp2000 either.
>>
>> I have this in my copy of the MAINTAINERS file:
>>
>> ARM/INTEL IXP2000 ARM ARCHITECTURE
>> M:      Lennert Buytenhek <kernel@wantstofly.org>
>> L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> S:      Maintained
>>
>> It's missing an F: line, otherwise it suggests that the platform is still
>> maintained by Lennert and it certainly builds just fine. Unfortunately he
>> seems to have fallen off the edge of the planet at the end of last year.
> 
> FYI, here's a snippet of a conversation I just had with Lennert on IRC 
> today:
> 
> 13:05 < nico> do you still care about ixp2000?
> 13:22 < lennert> not really, no
> 13:58 < nico> do you think we could remove it from the kernel tree?
> 14:01 < lennert> go for it, and remove ixp23xx too while you're at it

So, can we do this for 3.4 or should wait for 3.5?

Rob

[PATCH] ARM: remove ixp2000 platform

[Russell King - ARM Linux]

On Mon, Mar 05, 2012 at 08:44:07PM -0600, Rob Herring wrote:
> So, can we do this for 3.4 or should wait for 3.5?

I'd say wait, otherwise we're going to see delete/modify conflicts
which are a pain to deal with.

[PATCH] ARM: remove ixp2000 platform

[Arnd Bergmann]

On Tuesday 06 March 2012, Nicolas Pitre wrote:
> On Tue, 28 Feb 2012, Arnd Bergmann wrote:
> 
> > On Tuesday 28 February 2012, Rob Herring wrote:
> > > ixp2000 has no commits other than tree-wide changes or refactoring since
> > > 2006. No maintainer is listed for ixp2000 either.
> > 
> > I have this in my copy of the MAINTAINERS file:
> > 
> > ARM/INTEL IXP2000 ARM ARCHITECTURE
> > M:      Lennert Buytenhek <kernel@wantstofly.org>
> > L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> > S:      Maintained
> > 
> > It's missing an F: line, otherwise it suggests that the platform is still
> > maintained by Lennert and it certainly builds just fine. Unfortunately he
> > seems to have fallen off the edge of the planet at the end of last year.
> 
> FYI, here's a snippet of a conversation I just had with Lennert on IRC 
> today:
> 
> 13:05 < nico> do you still care about ixp2000?
> 13:22 < lennert> not really, no
> 13:58 < nico> do you think we could remove it from the kernel tree?
> 14:01 < lennert> go for it, and remove ixp23xx too while you're at it

Ah, good to know that Lennert is actually still alive somewhere.

And removing ixp2xxx in 3.5 will certainly help us, too. 

Interestingly, that leaves ixp4xx as the only big-endian ARM platform.
I believe that ixp4xx is still being actively used quite a bit, but does
that include the big-endian ones? There is no immediate reason why we
would want to drop support for big-endian, but if it's not used at all,
that would be an interesting cleanup opportunity.

	Arnd

[PATCH] ARM: remove ixp2000 platform

[Nicolas Pitre]

On Tue, 6 Mar 2012, Arnd Bergmann wrote:

> On Tuesday 06 March 2012, Nicolas Pitre wrote:
> > FYI, here's a snippet of a conversation I just had with Lennert on IRC 
> > today:
> > 
> > 13:05 < nico> do you still care about ixp2000?
> > 13:22 < lennert> not really, no
> > 13:58 < nico> do you think we could remove it from the kernel tree?
> > 14:01 < lennert> go for it, and remove ixp23xx too while you're at it
> 
> Ah, good to know that Lennert is actually still alive somewhere.
> 
> And removing ixp2xxx in 3.5 will certainly help us, too. 
> 
> Interestingly, that leaves ixp4xx as the only big-endian ARM platform.
> I believe that ixp4xx is still being actively used quite a bit, but does
> that include the big-endian ones? There is no immediate reason why we
> would want to drop support for big-endian, but if it's not used at all,
> that would be an interesting cleanup opportunity.

The NSLU2 is (was) a quite popular NAS device and it is used in big 
endian by default.

The BE support isn't getting in the way of anything, so there is no 
reason to remove it, even if it isn't being used much.


Nicolas

[PATCH] ARM: remove ixp2000 platform

[Arnd Bergmann]

On Tuesday 06 March 2012, Nicolas Pitre wrote:
> The NSLU2 is (was) a quite popular NAS device and it is used in big 
> endian by default.
> 
> The BE support isn't getting in the way of anything, so there is no 
> reason to remove it, even if it isn't being used much.

Ok, that's what I thought, just making sure. If it was completely
dead code, things would be different.

	Arnd

[PATCH] ARM: remove ixp2000 platform

[Richard Cochran]

On Tue, Mar 06, 2012 at 05:10:53PM +0000, Arnd Bergmann wrote:
> On Tuesday 06 March 2012, Nicolas Pitre wrote:
> > The NSLU2 is (was) a quite popular NAS device and it is used in big 
> > endian by default.
> > 
> > The BE support isn't getting in the way of anything, so there is no 
> > reason to remove it, even if it isn't being used much.
> 
> Ok, that's what I thought, just making sure. If it was completely
> dead code, things would be different.

Obligatory Monty Python quote:

    "I'm not dead."
    "'Ere, he says he's not dead."
    "Yes he is."

Even though Intel dropped the IXP like a hot potato, people are still
actively using Linux on it, and in big endian mode.

Thanks,
Richard

[PATCH] ARM: remove ixp2000 platform

[Linus Walleij]

On Tue, Mar 6, 2012 at 5:51 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Tue, 6 Mar 2012, Arnd Bergmann wrote:
>> Interestingly, that leaves ixp4xx as the only big-endian ARM platform.
>> I believe that ixp4xx is still being actively used quite a bit, but does
>> that include the big-endian ones? There is no immediate reason why we
>> would want to drop support for big-endian, but if it's not used at all,
>> that would be an interesting cleanup opportunity.
>
> The NSLU2 is (was) a quite popular NAS device and it is used in big
> endian by default.
>
> The BE support isn't getting in the way of anything, so there is no
> reason to remove it, even if it isn't being used much.

Network equipment seems to like using BE.

I have some vague idea that this is beacuse IP packets are big
endian, and thus you can process them quickly by just casting fields
to e.g. u32 pointers and read them.

I don't know if this is true, but seems to much of a correlation to
be pure coincidence. Thus a pretty interesting subject in
embedded ARM not used for tablets/mobile/generic computing
kind of stuff.

Yours,
Linus Walleij

[PATCH] ARM: remove ixp2000 platform

[Russell King - ARM Linux]

On Wed, Mar 07, 2012 at 09:40:31AM +0100, Linus Walleij wrote:
> Network equipment seems to like using BE.
> 
> I have some vague idea that this is beacuse IP packets are big
> endian, and thus you can process them quickly by just casting fields
> to e.g. u32 pointers and read them.
> 
> I don't know if this is true, but seems to much of a correlation to
> be pure coincidence. Thus a pretty interesting subject in
> embedded ARM not used for tablets/mobile/generic computing
> kind of stuff.

ISTR Nicolas explained this to me as being an established thing in the
comms sector.  They expect BE and only understand BE.

I did point out that you end up with many more endian conversions by
going to BE, mainly because PCI is LE and all your PCI accesses have
to be endian-swapped.  So in terms of bandwidth, I'd expect an ARM
PCI platform running in BE mode to have worse throughput than a LE
PCI platform.

But... if BE allows the comms people to keep their warm fuzzy feeling
who are we to argue.

[PATCH] ARM: remove ixp2000 platform

[Greg Ungerer]

On 03/07/2012 07:14 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 07, 2012 at 09:40:31AM +0100, Linus Walleij wrote:
>> Network equipment seems to like using BE.
>>
>> I have some vague idea that this is beacuse IP packets are big
>> endian, and thus you can process them quickly by just casting fields
>> to e.g. u32 pointers and read them.
>>
>> I don't know if this is true, but seems to much of a correlation to
>> be pure coincidence. Thus a pretty interesting subject in
>> embedded ARM not used for tablets/mobile/generic computing
>> kind of stuff.
>
> ISTR Nicolas explained this to me as being an established thing in the
> comms sector.  They expect BE and only understand BE.
>
> I did point out that you end up with many more endian conversions by
> going to BE, mainly because PCI is LE and all your PCI accesses have
> to be endian-swapped.  So in terms of bandwidth, I'd expect an ARM
> PCI platform running in BE mode to have worse throughput than a LE
> PCI platform.

The built in ethernet interfaces on the ixp4xx family are not PCI
based. So they at least do not suffer from the BE/LE conversions
at the eth driver.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg at snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close,                            FAX:         +61 7 3891 3630
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

[PATCH] ARM: remove ixp2000 platform

[Imre Kaloz]

On Tue, 06 Mar 2012 15:11:59 +0100, Arnd Bergmann <arnd@arndb.de> wrote:

<snip>

>
> Interestingly, that leaves ixp4xx as the only big-endian ARM platform.
> I believe that ixp4xx is still being actively used quite a bit, but does
> that include the big-endian ones? There is no immediate reason why we
> would want to drop support for big-endian, but if it's not used at all,
> that would be an interesting cleanup opportunity.

IXP4xx is almost exclusively used in BE mode.


Imre

[PATCH] ARM: remove ixp2000 platform

[Krzysztof Halasa]

Greg Ungerer <gerg@snapgear.com> writes:

> The built in ethernet interfaces on the ixp4xx family are not PCI
> based. So they at least do not suffer from the BE/LE conversions
> at the eth driver.

The problematic one is IXP42x rev. A0. It has no support for hw mixed
mode (LE core + lane swapping where needed). Unfortunately this early
chip is quite popular. "Software" mixed mode means byte swapping in the
network drivers and IIRC the crypto accelerator becomes unusable (at
least without workarounds).

Later revisions (42x rev. B0 and up, and all other IXP4[356]) can work
in the most efficient hw mixed mode. Support is not upstream but it's
basically ready. I think it may be incompatible with XIP.
-- 
Krzysztof Halasa

[PATCH] ARM: remove ixp2000 platform

[Greg Ungerer]

On 11/03/12 22:31, Krzysztof Halasa wrote:
> Greg Ungerer<gerg@snapgear.com>  writes:
>
>> The built in ethernet interfaces on the ixp4xx family are not PCI
>> based. So they at least do not suffer from the BE/LE conversions
>> at the eth driver.
>
> The problematic one is IXP42x rev. A0. It has no support for hw mixed
> mode (LE core + lane swapping where needed). Unfortunately this early

It is not problematic if you are running your core BE right?

Regards
Greg



> chip is quite popular. "Software" mixed mode means byte swapping in the
> network drivers and IIRC the crypto accelerator becomes unusable (at
> least without workarounds).
>
> Later revisions (42x rev. B0 and up, and all other IXP4[356]) can work
> in the most efficient hw mixed mode. Support is not upstream but it's
> basically ready. I think it may be incompatible with XIP.


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg at snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

[PATCH] ARM: remove ixp2000 platform

[Krzysztof Halasa]

Greg Ungerer <gerg@snapgear.com> writes:

>> The problematic one is IXP42x rev. A0. It has no support for hw mixed
>> mode (LE core + lane swapping where needed). Unfortunately this early
>
> It is not problematic if you are running your core BE right?

Right.
Of course it requires lane-swapping between PCI and the core/RAM. The
chip is set to hardware swap these accesses (block transfers and binary
structure layouts are correct, including bus master transfers) and
integer data (mostly u16/u32) are swapped again by the core
(readl/writel, also in-memory descriptors etc). All other peripherals
are always BE (NPE net coprocessors, EXP bus).

This all works fine on all revisions including the IXP425-A0.
-- 
Krzysztof Halasa