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
