[PATCH v7 1/6] pci: Introduce pci_register_io_range() helper function.

(sorry for replying to a months old thread)

On Mon, Apr 07, 2014 at 06:58:24PM +0100, Bjorn Helgaas wrote:

On Mon, Apr 7, 2014 at 5:36 AM, Arnd Bergmann [off-list ref] wrote:

quoted

I think migrating other architectures to use the same code should be
a separate effort from adding a generic implementation that can be
used by arm64. It's probably a good idea to have patches to convert
arm32 and/or microblaze.

Let me reiterate that I am 100% in favor of replacing arch-specific
code with more generic implementations.

However, I am not 100% in favor of doing it as separate efforts
(although maybe I could be convinced).  The reasons I hesitate are
that (1) if only one architecture uses a new "generic" implementation,
we really don't know whether it is generic enough, (2) until I see the
patches to convert other architectures, I have to assume that I'm the
one who will write them, and (3) as soon as we add the code to
drivers/pci, it becomes partly my headache to maintain it, even if
only one arch benefits from it.

I agree and understand your point.

Please don't think I'm questioning anyone's intent or good will.  It's
just that I understand the business pressures, and I know how hard it
can be to justify this sort of work to one's management, especially
after the immediate problem has been solved.

But, unfortunately, that's something we failed to address in reasonable
time (even though I was one of the proponents of the generic PCIe
implementation). This work is very likely to slip further into the late
part of this year and I am aware that several ARM partners are blocked
on the (upstream) availability of PCIe support for the arm64 kernel.

Although a bit late, I'm raising this now and hopefully we'll come to a
conclusion soon. Delaying arm64 PCIe support even further is not a real
option, which leaves us with:

1. Someone else (with enough PCIe knowledge) volunteering to take over
   soon or
2. Dropping Liviu's work and going for an arm64-specific implementation
   (most likely based on the arm32 implementation, see below)

First option is ideal but there is work to do as laid out by Arnd here:

http://article.gmane.org/gmane.linux.kernel/1679304

The latest patches from Liviu are here (they only target arm64 and there
are additional comments to be addressed from the above thread):

http://linux-arm.org/git?p=linux-ld.git;a=shortlog;h=refs/heads/for-upstream/pci-next

The main reason for the second option is timing. We could temporarily
move Liviu's code under arch/arm64 with the hope that we generalise it
later. However, the risk is even higher that once the code is in
mainline, the generic implementation won't happen. In which case, I
don't see much point in departing from the arm32 PCI API, making bios32
clone the best second option.

For the alternative implementation above, we already have a heavily cut
down version of the arm32 PCI support but only tested in a virtual
environment so far:

https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/log/?h=pci/bios32

In conclusion, unless someone volunteers for the first option fairly
soon, we'll post the alternative patches for review and take it from
there.

Thanks.

-- 
Catalin