linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: Jiri Slaby <jirislaby@gmail.com>, Jeff Garzik <jeff@garzik.org>,
	"John W. Linville" <linville@tuxdriver.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] revert ath5k ioread32()/iowrite32() usage - use  readl()/writel(), we're MMIO-only
Date: Wed, 19 Sep 2007 08:18:54 +1000	[thread overview]
Message-ID: <1190153934.6403.123.camel@localhost.localdomain> (raw)
In-Reply-To: <43e72e890709181212u75ec6fe2x7aa639bac319c087@mail.gmail.com>


> > > > If the driver knows its MMIO, using readX/writeX after pci_iomap() is
> > > > just fine, for all current implementations, and it makes sense that way.
> > >
> > > There is nothing that guarantees this is permitted, any more than there
> > > is anything saying not to use outb/outl. Some of the implementations do
> > > quite strange things. It may happen to work but its not in the
> > > documentation or the comments.
> >
> > I posted a patch to update the documentation with this.
> >
> > > Please, can anybody clarify it?
> >
> > Based on Alan's 'Review-by' remarks on my patch for updating the
> > documenation on pci_iomap() it seems this validates this patch. Please
> > see thread with subject:
> >
> > [PATCH] Clarify pci_iomap() usage for MMIO-only devices
> 
> Well spoke too soon. Now Linus disagrees. We'll see the outcome on the
> other thread then.

To be more precise, a platform has every right to return some kind of
"token" from ioport_map/pci_iomap that encodes the type of address, and
that is -different- from what a normal ioremap does. In which case, you
will -not- be able to use readb/writeb & cie on such a token.

The fact that current implementations seem to return something for MMIO
that is equivalent to what ioremap returns is an accident and cannot be
relied upon.

Cheers,
Ben.



  reply	other threads:[~2007-09-18 22:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-17 20:34 [PATCH] revert ath5k ioread32()/iowrite32() usage - use readl()/writel(), we're MMIO-only Luis R. Rodriguez
2007-09-17 20:44 ` Jiri Slaby
2007-09-17 20:59   ` Jeff Garzik
2007-09-17 21:44     ` Jiri Slaby
2007-09-18 19:03       ` Luis R. Rodriguez
2007-09-18 19:12         ` Luis R. Rodriguez
2007-09-18 22:18           ` Benjamin Herrenschmidt [this message]
2007-09-18 22:44             ` Jeff Garzik
2007-09-17 20:59   ` Luis R. Rodriguez

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=1190153934.6403.123.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jeff@garzik.org \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mcgrof@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).