USB support on mpc5200 broken

Carsten Schlote c.schlote at
Wed Oct 1 19:46:29 EST 2008

Hi Ben,

> Note about the Amiga stuff: it's a bad idea :-) Every attempt 
> at "magically" fixing endian in HW is a recipe for tears and 
> disasters.

I fully agree. It's one of the problem I encountered with some similiar
approach on some other big-endian Freescale CPU. It is implemented as a
hard-wired 'endian-swap feature' and it simply makes everything much
more complicated for code intended to run on LE and BE CPU by virtually
adding some additional special case. 

> Approximately ... always. The only cases that I know that 
> have a remote chance of being useful are specifically 
> programmable swappers on a given device or per-page endian 
> configuration in the processor (like BooKE).

Also agree. There might be use-cases, where hardware-supported
endian-swapping might be useful. But it must be an optional feature. 

It's already some PITA to develope and maintain drivers running on LE/BE
CPUs and to properly access word and longword PCI registers
endian-transparent. Byte streams should never be affected by endianess

Automatic endian-swapping might speed up some register accesses or e.g.
framebuffer accesses (reverse pixel endianess), but in general it adds
more problems than it's worth. 

The framebuffer use-case is currently the only one, where such a
hardware-swapper could be really useful. But still the drivers would
have to know about this feature, it would require query/set macros/fcts
for endian translation modes in the kernel, ... - in short it causes
lots of extra overhead. And for framebuffers the need for such hard-ware
swappers can be eleminated by using the right framebuffer mode.

I fear, that such hard-wired 'magic' swapping is the source and reason
for some of my current problems.


More information about the Linuxppc-dev mailing list