linux-kernel - Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)

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, 6 Feb 2013 16:18:07 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Michal Simek <monstr@...str.eu>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
	linux-kernel@...r.kernel.org, grant.likely@...retlab.ca,
	alan@...rguk.ukuu.org.uk, dahinds@...rs.sourceforge.net
Subject: Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

On Wednesday 06 February 2013, Geert Uytterhoeven wrote:
> On Wed, Feb 6, 2013 at 12:03 AM, Arnd Bergmann <arnd@...db.de> wrote:
> > On Tuesday 05 February 2013, Michal Simek wrote:
> >> I want to be sure about this. I have parsed this again with closer look and
> >> seems to me that ioread32 is equal to readl and iowrite32 to writel.
> >> Arnd: Am I right?
> >
> > Correct. On all the architectures you care about (most importantly, not
> > x86), readl and ioread32 are defined to have the same semantics. There
> > are a few exceptions where ioread32 provides a wrapper for PCI
> > PIO accesses that are not memory mapped, making ioread32 slightly
> > slower than readl, but for all practical purposes you don't have
> > to worry about it ;-)
> 
> PCI PIO? Do you mean "PCI I/O space"?

Yes.

> That's different, and accessed through inb() and friends, right?

Sort of. The native methods are readl() etc for MMIO and inb() etc. for PIO,
as you say. However, the ioread32() family does the superset of the two,
either using a wrapper function with a mangled port number / pointer
argument (e.g. on x86), or it gets defined to do the same as readl on
platforms where the PCI I/O space is memory mapped. The requirement
here is that whatever the result of ioport_map() is must be turned
back into a PIO access when passed into ioread32(). On memory mapped
platforms, there is typically just an offset that gets added to the
port number to turn that into an __iomem pointer.

	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/