From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Liviu Dudau <Liviu.Dudau@arm.com>, Michael Ellerman <mpe@ellerman.id.au>
Cc: 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 14:58:37 +1100 [thread overview]
Message-ID: <1413431917.11213.56.camel@pasglop> (raw)
In-Reply-To: <1413428148.20705.2.camel@concordia>
On Thu, 2014-10-16 at 13:55 +1100, Michael Ellerman wrote:
> Yes, we already provide our own version of pci_address_to_pio().
>
> The problem is it's too early to call it when we come in from
> find_and_init_phbs() -> pci_process_bridge_OF_ranges(), so it returns junk.
>
> I think you were expecting us to hit the #ifndef PCI_IOBASE case, which looks
> like it might have worked.
>
> For now we're just going to stop using of_pci_range_to_resource().
Right, this is a band-aid to fix things now. For the long run, I think we could
exploit Liviu's code with a few changes:
- We would want to add a variant of pci_register_io_range() that takes the actual
PIO address as an argument so we can use it to "register" our ranges on ppc64
since we decide where in IO space they go using our own algorithm and we don't
want to change that. That would make the generic pci_pio_to_address() and
pci_address_to_pio() work for us. At least for ppc64.
- For ppc32, we might want to consider changing the horrible pointer arithmetic
we do today (which keeps breaking) and just switch to the allocator inside
pci_register_io_range() and use it like ARM does.
- I object to of_pci_range_to_resource() implicitly doing the allocation/registration
of the range. It should fail if the range isn't registered. The architecture code
should explicitly register the IO ranges before trying to turn them into resources.
Now, this will take a bit more time to sort out (and the latter comment will
mean, if addressed, some changes to the new ARM code which I don't think I have
the bandwidth to do), so I'm happy to settle for whatever band-aid Michael is
coming up with for 3.18 but we should consider improving things for .19
Cheers,
Ben.
next prev parent reply other threads:[~2014-10-16 3:59 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 [this message]
2014-10-16 9:05 ` Liviu Dudau
2014-10-16 10:04 ` Benjamin Herrenschmidt
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=1413431917.11213.56.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