From: Kyle McMartin <kyle@mcmartin.ca>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Kyle McMartin <kyle@mcmartin.ca>,
Arjan van de Ven <arjan@infradead.org>,
Grant Grundler <grundler@parisc-linux.org>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH] pci: introduce users of ioremap_pcibar()
Date: Wed, 1 Oct 2008 09:07:17 -0400 [thread overview]
Message-ID: <20081001130717.GE10632@phobos.i.cabal.ca> (raw)
In-Reply-To: <20081001125711.GG13822@parisc-linux.org>
On Wed, Oct 01, 2008 at 06:57:11AM -0600, Matthew Wilcox wrote:
> > If they use the iomap interface they shouldn't be using readl at all,
> > they should be using ioread*... It would be a bug otherwise.
>
> That's a viewpoint I've heard several people espouse over the last few
> days, but it's not (entirely) true. Addresses returned from calling
> iomap() on a memory location must be compatible with addresses returned
> from calling ioremap(), so you can use readl() on an iomap address, as
> long as you know that it was a memory address that was iomapped.
>
> if (flags & IORESOURCE_MEM) {
> if (flags & IORESOURCE_CACHEABLE)
> return ioremap(start, len);
> return ioremap_nocache(start, len);
> }
>
> OK, not all architectures use the generic code, but I've been through
> and they all do more or less the above (mn10300 and frv just return the
> address, but their readl() and inl() are identical)
>
I don't recall anyone ever promising that the iomap interfaces would be
usable with legacy accessors. I'd certainly prefer it if we didn't, as
well, as it makes for more explicitly written drivers...
Just because you can use them, doesn't mean you should.
regards, Kyle
next prev parent reply other threads:[~2008-10-01 13:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-26 23:36 [PATCH] pci: introduce an ioremap_pcibar(pdev, barnr) function Arjan van de Ven
2008-09-26 23:37 ` [PATCH] pci: introduce users of ioremap_pcibar() Arjan van de Ven
2008-09-29 7:26 ` Grant Grundler
2008-09-29 9:20 ` Alan Cox
2008-09-29 13:42 ` Arjan van de Ven
2008-09-29 17:10 ` Grant Grundler
2008-09-29 17:23 ` Arjan van de Ven
2008-10-01 5:24 ` Grant Grundler
2008-09-30 22:30 ` Arjan van de Ven
2008-10-01 10:33 ` Rolf Eike Beer
2008-10-01 12:42 ` Kyle McMartin
2008-10-01 12:57 ` Matthew Wilcox
2008-10-01 13:07 ` Kyle McMartin [this message]
2008-10-01 13:53 ` Arjan van de Ven
2008-09-27 2:56 ` [PATCH] pci: introduce an ioremap_pcibar(pdev, barnr) function Matthew Wilcox
2008-09-27 15:35 ` Arjan van de Ven
-- strict thread matches above, loose matches on Subject: below --
2008-09-29 18:08 [PATCH] pci: introduce users of ioremap_pcibar() Marin Mitov
2008-10-01 6:39 Marin Mitov
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=20081001130717.GE10632@phobos.i.cabal.ca \
--to=kyle@mcmartin.ca \
--cc=arjan@infradead.org \
--cc=grundler@parisc-linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew@wil.cx \
/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