Re: [PATCH] PCI: Avoid handing out address 0 to devices

[Bjorn Helgaas <helgaas@kernel.org>]

On Sat, Feb 26, 2022 at 10:47:10AM +0000, Maciej W. Rozycki wrote:
> We have numerous platforms that permit assigning addresses from 0 to PCI 
> devices, both in the memory and the I/O bus space, and we happily do so 
> if there is no conflict, e.g.:
> 
> pci 0000:07:00.0: BAR 0: assigned [io  0x0000-0x0007]
> pci 0000:07:00.1: BAR 0: assigned [io  0x0008-0x000f]
> pci 0000:06:01.0: PCI bridge to [bus 07]
> pci 0000:06:01.0:   bridge window [io  0x0000-0x0fff]
> 
> (with the SiFive HiFive Unmatched RISC-V board and a dual serial port 
> option card based on the OxSemi OXPCIe952 device wired for the legacy 
> UART mode).
> 
> Address 0 is treated specially however in many places, for example in 
> `pci_iomap_range' and `pci_iomap_wc_range' we require that the start 
> address is non-zero, and even if we let such an address through, then 
> individual device drivers could reject a request to handle a device at 
> such an address, such as in `uart_configure_port'.  Consequently given
> devices configured as shown above only one is actually usable:

pci_iomap_range() tests the resource start, i.e., the CPU address.  I
guess the implication is that on RISC-V, the CPU-side port address is
the same as the PCI bus port address?

Is that actually a requirement?  Maybe you could also avoid this by
remapping the ports in CPU address space?

Is the same true for PCI memory addresses?  They are identical to CPU
addresses, i.e., no translation is applied?

On the PCI side, zero is a perfectly valid address, so it's a shame to
throw it away if we don't have to, especially since throwing away even
16 bytes of MMIO space means a 4GB 32-bit BAR cannot be mapped at all.

Bjorn