arm64 PCI resource allocation issue

[Lorenzo Pieralisi]

On Tue, Aug 02, 2022 at 02:07:00PM +1000, Benjamin Herrenschmidt wrote:

[...]

> The case back then was that there existed some (how many ? there was
> one real example if I remember correctly) bogus firwmares that came out
> of UEFI with too small windows. We could just quirk those ....

There is just one way to discover "how many" unfortunately, quirking
those can be more problematic than it seems.

[...]

> The alternative here would be to use ad-hock kludges for such system
> devices, to "register" the addresses early, and have some kind of hook
> in the PCI code that keeps track of them as they get remapped.

That's what x86 does AFAICS (pcibios_save_fw_addr()), even though
it is used in a different scope (ie revert to FW address if the
resource allocation fails).

> If we want this, I would propose (happy to provide the implementation
> but let's discuss the design first) something along the line of a
> generic mechanism to "register" such a system device, which would add
> it to a list. That list would be scanned on PCI device discovery for
> BAR address matches, and the pci_dev/BAR# added to the entry (that or
> put a pointer to the entry into pci_dev for speed/efficiency).
> 
> The difficulty is how is that update propagated:
> 
> This is of course fiddly. For example, the serial info is passed via
> two different ways, one being earlycon (and probably the easiest to
> track), the other one an ASCII string passed to
> add_preferred_console(), which would require more significant hackery
> (the code dealing with console mathing is a gothic horror).
> 
> Also if such a system device is in continuous use during the boot
> process (UART ?) it needs to be "updated" as soon as possible after the
> BARs (and parent BARs) have been also updated (in fact this is
> generally why PCI debug dies horribly when using PCI based UARTs).
> Maybe an (optional) callback that earlycon can add ?
> 
> Additionally, this would only work if such system devices are
> "registered" before they get remapped... 
> 
> Another approach would be to have pci_dev keep a copy of the original
> resources (at least for the primary BARs) and provide an accessor for
> use by things like earlycon or 8250 to compare against these, though
> that doesn't solve the problem of promptly "updating" drivers for
> system devices.
> 
> Opinions ?

You may also want to look into IORESOURCE_PCI_FIXED even though the
last time I looked into I found some broken logic (basically the
immutable/"fixed" BAR resources should obviously take into account the
PCI tree hierarchy - upstream bridges, etc., which I don't think
IORESOURCE_PCI_FIXED does - how it works remains a bit of
a mystery for me).

Lorenzo