[PATCH 1/3] ARM: pci: make bus I/O resources optional

[Arnd Bergmann]

On Fri, Mar 26, 2021 at 2:39 PM Russell King - ARM Linux admin
<linux at armlinux.org.uk> wrote:
>
> On Fri, Mar 26, 2021 at 02:33:15PM +0100, Arnd Bergmann wrote:
> > Leaving out the lower 0x1000 port numbers in turn is required so
> > legacy ISA drivers acquire the ports with request_region(). The reason
> > it broke on your machine was apparently that pci_claim_resource()
> > failed to assign the low port numbers to the PCI bus after that has
> > explicitly set the minimum.
>
> No, this is totally broken thinking. The 0x1000 offset is *purely* a
> PCI resource *allocation* issue, nothing more nothing less. To argue
> otherwise just shows a lack of understanding of what is going on here.
>
> _All_ resources from IO port 0 to 0xffff are on the PCI bus in this
> case. It makes no sense to create a PCI bus resource for 0x1000-0xffff.
> That is entirely illogical and ficticious.
>
> > Using ioport_resource as the PCI host bridge resource as you do
> > is the easiest way to make it work for both ISA drivers and PCI drivers
> > using low I/O ports.
>
> The fact is, in these machines, the ISA bus is _behind_ the PCI bus,
> just like it is on x86 PCs and Alpha. There's no difference here.

The problem I'm referring to is a set conflicting requirements:

1. all ISA devices must have port resources that are direct
  children of ioport_resource. This is independent of how the
  ISA bus is physically attached.

2. If there are multiple PCI host bridges that have physically
  separate I/O port ranges.

3. Any PCI device with I/O ports must have a corresponding
  resource that is a subset of the PCI host bridge->windows
  list

4. Old style PCI IDE devices and a few others must have their
  I/O ports set to within the ISA range.

I don't think there is any good solution that covers the entire
set. In case of footbridge and old PCs, Using ioport_resource
in bridge->windows as you do works fine because there is only
a single physical port range. But because it breaks constraint
#2 in the list, it wouldn't work in general.

The current code works for constraint #2, but breaks #4, so you
can't have an PCI IDE adapter.

arch/x86/pci/broadcom_bus.c manages to address all of the
above by adding the IDE resources directly into the PCI
host bridge resources, but this is platform specific and not
needed on footbridge because you don't care about #2.

        Arnd