ARM: remove ixp2000 platform

ixp2000 has no commits other than tree-wide changes or refactoring since 2006. No maintainer is listed for ixp2000 either.

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.

Quoted 2 lines · Rob Herring

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 <[email protected]>
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.

Quoted 6 lines · Arnd Bergmann

Quoted 2 lines · Rob Herring

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:

Quoted 8 lines

ARM/INTEL IXP2000 ARM ARCHITECTURE

M:      Lennert Buytenhek <[email protected]>
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?

Quoted 6 lines · Arnd Bergmann

Quoted 2 lines · Rob Herring

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:

Quoted 8 lines

ARM/INTEL IXP2000 ARM ARCHITECTURE

M:      Lennert Buytenhek <[email protected]>
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

Quoted 7 lines · Nicolas Pitre

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.

Quoted 5 lines · Nicolas Pitre

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.

Quoted 5 lines · Arnd Bergmann

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.

Quoted 10 lines · Linus Walleij

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.

Quoted 3 lines · Greg Ungerer

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.

Quoted 2 lines

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?

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.