[PATCH] arm: fix regression in ixp4xx clocksource

[Mikael Pettersson]

Richard Cochran writes:
 > On Wed, Jun 01, 2011 at 11:58:26PM +0100, Russell King - ARM Linux wrote:
 > > On Mon, May 30, 2011 at 10:43:07AM +0200, Richard Cochran wrote:
 > > > Commit 234b6ceddb4fc2a4bc5b9a7670f070f6e69e0868
 > > > 
 > > >    clocksource: convert ARM 32-bit up counting clocksources
 > > > 
 > > > broke the build for ixp4xx and made big endian operation impossible.
 > > > This commit restores the original behaviour.
 > > 
 > > I'm really not happy about using the MMIO clocksource stuff with random
 > > other read functions like this - it defeats the entire purpose of the
 > > MMIO clocksource stuff.  Maybe we should just undo the change for IXP4xx
 > > and treat it as "special" for the time being.
 > 
 > I took another look at the whole MMIO clocksource implementation and
 > can't understand why all of the accessors use le_to_cpu. This seems to
 > imply that all peripheral buses are little endian (except for ixp,
 > which no one cares about, anyhow).

"no one"? ixp4xx is still being used.

 > I understand (or have been told) that almost all arm implementations
 > out there are little endian. Why not use use a normal load to read the
 > timer? Are there machines with LE peripheral buses but BE cores?

ARM cores often have software-controllable endianess (see the ARM ARM).
Off the top of my head:
- ixp4xx: natively BE core and peripherals, but some people like to
  switch the core to LE for user-space SW compatibility reasons
  (I run my ixp4xx in BE as intended though)
- Kirkwood: natively LE core and peripherals, but the core is switchable
  to BE, although driver support for that appears to be incomplete

And then there were the old chips where the integer core and the FPA
(ancient FPU) could run with different endianesses ... lots of software
had problems with that; I'm glad EABI and VFP put an end to that insanity.