[PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings

Russell King - ARM Linux linux at armlinux.org.uk
Wed Apr 12 07:31:24 EDT 2017


On Wed, Apr 12, 2017 at 09:12:51AM +1000, Benjamin Herrenschmidt wrote:
> This is a problem to be solved by the bridge itself. If ARM has a
> mapping attribute to make stores non-posted, keep this an ARM specific
> attribute at this stage I'd say.

So what you seem to be saying is to place drivers not in drivers/pci/host
but in arch/arm, and a duplicate copy in arch/arm64.

No.  We're way past that by popular concensus.  We're not going back to
doing what we did in the 2000s.  Drivers go in the drivers subtree,
period.  That means we require architecture interfaces that provide
access to architecture specific details that may not be suitable for
all architectures to support.

In the case of something brand new, then I agree with you that the
default implementation should fail if it's not supportable on all
architectures.  However, when we have existing drivers using an
interface that doesn't provide the semantics they already require,
then it makes no sense to effectively break these drivers on a range
of existing architectures.

The question really is - what's the best way to solve the problem with
existing drivers without breaking them.  I suspect that, sadly, the
only realistic way forward here is via the litter-drivers-with-ifdefs
approach since you don't like providing a default implementation that
is compatible with what these drivers are already doing.

Drivers, such as:

drivers/pci/host/pci-mvebu.c
drivers/pci/host/pci-versatile.c
drivers/pci/host/pci-xgene.c

to name a few.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.



More information about the linux-arm-kernel mailing list