On Tue, Nov 22, 2022 at 11:45:41AM +0000, Jonathan Cameron wrote: > On Tue, 22 Nov 2022 08:42:58 +0200 > Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > On Mon, Nov 21, 2022 at 04:45:48PM -0600, Bjorn Helgaas wrote: > > > IIUC, the summary is this: > > > > > > 00:02.0 bridge window [mem 0x10000000-0x102fffff] to [bus 01-02] > > > 01:02.0 bridge window [mem 0x10000000-0x100fffff] to [bus 02] > > > 01:03.0 NIC BAR [mem 0x10200000-0x1021ffff] > > > 01:04.0 NIC BAR [mem 0x10220000-0x1023ffff] > > > 02:05.0 NIC BAR [mem 0x10080000-0x1009ffff] > > > > > > and it's the same with and without the current patch. > > > > > > Are all these assignments done by BIOS, or did Linux update them? > > > > > Did we exercise the same "distribute available resources" path as in > > > the PCIe case? I expect we *should*, because there really shouldn't > > > be any PCI vs PCIe differences in how resources are handled. This is > > > why I'm not comfortable with assumptions here that depend on PCIe. > > > > > > I can't tell from Jonathan's PCIe case whether we got a working config > > > from BIOS or not because our logging of bridge windows is kind of > > > poor. > > > > This is ARM64 so there is no "BIOS" involved (something similar though). > > It's EDK2 in my tests - so very similar to other arch. > Possible to boot without though and rely on DT, but various things don't > work yet... Doesn't matter whether it's BIOS/EFI/EDK2/etc, the question was really whether anything has programmed BARs and windows before Linux gets started. > From liberal distribution of printk()s it seems that for PCI bridges > pci_bridge_resources_not_assigned() is false, but for PCI express > example it is true. My first instinct is quirk of the EDK2 handling? > I'll have a dig, but I'm not an expert in EDK2 at all, so may not get > to the bottom of this. I don't know what pci_bridge_resources_not_assigned() is. > Ultimately it seems that when the OS takes over the prefetchable memory > resources are not configured for the PCIe case, but are for the PCI case. > So we aren't currently walking the new code for PCI. Whatever the reason for this is, it doesn't sound like something Linux should assume or rely on. Bjorn
