Re: Do cpu-endian MMIO accessors exist?

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 22 July 2009, Pekka Paalanen wrote:
> > The powerpc in_le32 style functions are a completely different
> > story, they are basically defined to operate only on on-chip
> > components, while ioread32 and readl do work on PCI devices.
> 
> So what should I use on BE arches when the card is in BE mode?
> Not out_be32() but iowrite32be()?
> I never even noticed that io*be() functions exist, thanks for the hint.

If it's a PCI/AGP/PCIe device, use iowrite32be(), otherwise it
may not work correctly on a pseries, celleb or qs20 machine.

If it's connected over a different bus (IOIF on PS3), out_be32
would be more appropriate, but AFAICT, iowrite32be should work
just as well.

> On LE arches I'll stick to {read,write}[bwl], which in my
> understanding always handle the hardware as LE. Right?

Right. For consistency you could decide to switch to iowrite32()
to go along with iowrite32be(), that should be equivalent on
MMIO based devices to writel.

> > It would of course be easy to just define an API extension
> > to ioread along the lines of
> > 
> > #ifdef __BIG_ENDIAN
> > #define ioread16_native ioread16be
> > #define ioread32_native ioread32be
> > #define iowrite16_native iowrite16be
> > #define iowrite32_native iowrite32be
> > #else
> > #define ioread16_native ioread16
> > #define ioread32_native ioread32
> > #define iowrite16_native iowrite16
> > #define iowrite32_native iowrite32
> > #endif
> > 
> > but I'm not yet convinced that there is a potential user that
> > should not just be fixed in a different way.
> 
> This is how it currently is.

Well, I meant we could add it to asm-generic/iomap.h. If we
decide that this is the right approach after all, it should
be part of the common linux API, not private to a single driver.

	Arnd <><