mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Jeff Garzik <jgarzik@pobox.com>, Andrew Morton <akpm@osdl.org>,
	"David S. Miller" <davem@davemloft.net>,
	Paul Mackerras <paulus@samba.org>
Subject: Re: lib/iomap.c mmio_{in,out}s* vs. __raw_* accessors
Date: Sat, 4 Nov 2006 15:52:57 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0611041544030.25218@g5.osdl.org> (raw)
In-Reply-To: <1162678639.28571.63.camel@localhost.localdomain>



On Sun, 5 Nov 2006, Benjamin Herrenschmidt wrote:
> 
> I'm tempted to remove those mmio_* things from iomap.c completely. I
> need to check who uses them, but in all cases, I don't see what they do
> in iomap.c, it's not their place.

I don't think you understand the point. The point is that a lot of the 
tests for whether something is MMIO or PIO can be done _once_, instead of 
doing it for every access.

> Versions that would transparently use MMIO or PIO would make sense.

No, they would be idiotic, because we already have those. If you want to 
use MMIO or PIO transparently one access at a time, YOU SHOULD NOT USE THE 
"STRING" VERSION. You should just use "ioread8()" or something like that. 

That _is_ the single-access-does-MMIO-or-PIO-transparently function!

> A pure MMIO implementation doesn't, that has to be arch specific. It makes
> the generic iomap suddently non-portable in some ways.

Whaa? I really don't see what's wrong with the one that is in lib/iomap.c. 
But if you want to do your own, go ahead and do so - the whole point of 
lib/iomap.c is to be a library that can be used by architectures that can 
use the generic functionality. It's all hidden behind 
CONFIG_GENERIC_IOMAP.

In other words, this whole thread makes absolutely _zero_ sense. Either 
you use those functions or you don't. Trying to change them would be 
insane.

> So I think we need to make sure all archs grow readsb,sw,sl etc... and
> just have iomap use those for the "transparent" versions.

Again, totally insane. If you don't want to use GENERIC_IOMAP, don't. But 
don't force other architectures to follow that path to insanity.

So, in short:
 (a) if the generic library doesn't work for you, stop using it

 (b) the whole _point_ of the "repeat" instructions is to avoid doing the 
     same tests over and over again for an iomem address that won't 
     change, so doing them in the individual accessor functions would be 
     _crazy_.

 (c) if you want to add #IO barriers to that thing, again, do it _around_ 
     the repeat string, not in the individual accesses. If you need them 
     on an individual access basis, you're probably better off doing your 
     own version altogether.

Please explain what is so wrong with the current setup, and please explain 
why you'd want to break the obvious "check the address only once!" rule 
that makes sense for _any_ architecture that has separate #PIO and #MMIO 
address spaces.

			Linus

  reply	other threads:[~2006-11-04 23:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-04  7:52 Benjamin Herrenschmidt
2006-11-04 14:06 ` Russell King
2006-11-04 22:17   ` Benjamin Herrenschmidt
2006-11-04 23:52     ` Linus Torvalds [this message]
2006-11-05  1:10       ` Benjamin Herrenschmidt
2006-11-05  3:32         ` Benjamin Herrenschmidt
2006-11-05  3:46           ` Linus Torvalds
2006-11-05  3:55             ` Benjamin Herrenschmidt
2006-11-05  4:00             ` Benjamin Herrenschmidt
2006-11-05  4:16               ` Linus Torvalds
2006-11-05  4:38                 ` Benjamin Herrenschmidt
2006-11-05  5:00                   ` Linus Torvalds
2006-11-05  5:08                     ` Benjamin Herrenschmidt
2006-11-05  5:28                       ` Benjamin Herrenschmidt
2006-11-06  2:56                         ` Benjamin Herrenschmidt
2006-11-06  3:13                           ` Linus Torvalds
2006-11-06  4:50                             ` Benjamin Herrenschmidt
2006-11-05  3:34         ` Linus Torvalds
2006-11-05  3:49           ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0611041544030.25218@g5.osdl.org \
    --to=torvalds@osdl.org \
    --cc=akpm@osdl.org \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®