From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Linus Walleij <linus.walleij@linaro.org>,
linux-pci <linux-pci@vger.kernel.org>
Subject: Re: of/pci: Fix the conversion of IO ranges into IO resources
Date: Thu, 16 Oct 2014 21:04:42 +1100 [thread overview]
Message-ID: <1413453882.11213.95.camel@pasglop> (raw)
In-Reply-To: <20141016090529.GG4599@e106497-lin.cambridge.arm.com>
On Thu, 2014-10-16 at 10:05 +0100, Liviu Dudau wrote:
> So you are going to continue converting IO ranges as IORESOURCE_MEM resources but with a
> different flag. Is that something that powerpc depends on or is it an artifact of too
> much code living around the kernel that has built in assumption of that being the fact?
> I'm trying to understand the world around powerpc so as to attempt to make a useful
> contribution in the future.
I'm not sure I understand what you mean and which specific resources you
are talking about.
For PCI devices, the IO BAR resources have IORESOURCE_IO ...
The case where we might get an IORESOURCE_MEM, at least that's how my old
code used to work, was is if we try to use the device-tree to convert a
PCI IO device address before we have initialized our mappings (ie, before
we have probed our PCI host bridges).
In that case, we would get an IORESOURCE_MEM (which is functional as long
as one ioremap's and uses the proper accessors for memory resources).
Once we have the PCI host bridges probed, the IO space is assigned, and
such conversion routines will transform the addresses properly into IO
resources.
Note that it's fairly rare that we use the device-tree for PCI based
resources anyway and even rarer than we do that before the PCI host
bridges have been properly setup and thus their IO space allocated.
Note that the problems exposed by these patches can be entirely reproduced
in qemu using virtio, so you should be able to test a little bit if you
have a reasonably fast x86 box to run qemu on.
Cheers,
Ben.
next prev parent reply other threads:[~2014-10-16 10:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20141009200235.55E5166107E@gitolite.kernel.org>
2014-10-15 7:35 ` of/pci: Fix the conversion of IO ranges into IO resources Benjamin Herrenschmidt
2014-10-15 9:02 ` Liviu Dudau
2014-10-16 2:55 ` Michael Ellerman
2014-10-16 3:58 ` Benjamin Herrenschmidt
2014-10-16 9:05 ` Liviu Dudau
2014-10-16 10:04 ` Benjamin Herrenschmidt [this message]
2014-10-16 10:28 ` Liviu Dudau
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=1413453882.11213.95.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=Liviu.Dudau@arm.com \
--cc=bhelgaas@google.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mpe@ellerman.id.au \
/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