linux-kernel - Re: Do cpu-endian MMIO accessors exist?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Jul 2009 23:20:58 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Pekka Paalanen <pq@....fi>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Jiri Slaby <jirislaby@...il.com>, linux-kernel@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Do cpu-endian MMIO accessors exist?

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 <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/