linux-kernel - Re: lib/iomap.c mmio_{in,out}s* vs. __raw

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:	Sat, 4 Nov 2006 19:34:19 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc:	Russell King <rmk+lkml@....linux.org.uk>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jgarzik@...ox.com>, Andrew Morton <akpm@...l.org>,
	"David S. Miller" <davem@...emloft.net>,
	Paul Mackerras <paulus@...ba.org>
Subject: Re: lib/iomap.c mmio_{in,out}s* vs. __raw_* accessors

On Sun, 5 Nov 2006, Benjamin Herrenschmidt wrote:
> 
> The -only- problem I'm talking about is that in order to implement the
> above, this IOCOND does something around the line of:
> 
> 	if (pio)
> 		use_pio_accessor()
> 	else
> 		use_mmio_accessor()
> 
> It does that, by using the existing, arch provided, accessors for PIO
> and MMIO (inX, outX, readX, writeX), which are doing the right thing vs.
> barriers etc, so again, all is good and well.... until you hit cases
> where such accessors don't exist !

Right. Your first email seemed to make sense. However, you then said (in 
the second email, the one I responded to), and THAT didn't make any sense 
at all:

   Versions that would transparently use MMIO or PIO would make sense. A
   pure MMIO implementation doesn't, that has to be arch specific. It makes
   the generic iomap suddently non-portable in some ways.

This is the part I claim says that you don't seem to make any sense. You 
seemed to be missing the point about the whole "repeat" instructions, 
since the WHOLE POINT there was that it would _not_ transparently use MMIO 
or PIO, it would very much _nontransparently_ use one or the other, 
exactly because the choice has already very much been made.

> 	- "be" versions of MMIO accesses. Example:

Now, this one we should probably just drop, because nobody uses it. 
Big-endian IO devices basically don't exist any more, and if they do, they 
wouldn't use any generic structures.

> 	- repeat versions of MMIO accessors. Example:

So this one is the only one that makes sense. But it DOES NOT MAKE SENSE 
in light of your second email that talked about "transparently use MMIO or 
PIO". That's what made me think that you were just blathering.

But I also don't want to add _yet_another_ bogus IO accessor function to 
all architectures that nobody actually uses except for this one little 
thing. Quite frankly, I'd rather just add something like

	#ifndef iobarrier_w
	# define iobarrier_w() do { } while (0)
	#endif

and then use iobarrier_w()" in the "mmio" version of the __raw_writel loop 
(and same for iobarrier_r() for the __raw_readl).

			Linus
-
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/