Re: [PATCH 1/2] PCI: Setup bridge resources earlier

[Val Packett]

On 10/6/25 7:46 AM, Ilpo Järvinen wrote:
> On Mon, 6 Oct 2025, Val Packett wrote:
> > On 9/24/25 10:42 AM, Ilpo Järvinen wrote:
> > > Bridge windows are read twice from PCI Config Space, the first read is
> > > made from pci_read_bridge_windows() which does not setup the device's
> > > resources. It causes problems down the road as child resources of the
> > > bridge cannot check whether they reside within the bridge window or
> > > not.
> > >
> > > Setup the bridge windows already in pci_read_bridge_windows().
> > >
> > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
> > Looks like this change has broken the WiFi (but not NVMe) on my Snapdragon X1E
> > laptop (Latitude 7455):
> Thanks for the report.
>
> > qcom-pcie 1c08000.pci: PCI host bridge to bus 0004:00
> > pci_bus 0004:00: root bus resource [bus 00-ff]
> > pci_bus 0004:00: root bus resource [io  0x100000-0x1fffff] (bus address [0x0000-0xfffff])
> So this looks the first change visible in the fragment you've taken from
> the dmesg...
>
> > pci_bus 0004:00: root bus resource [mem 0x7c300000-0x7dffffff]
> > pci 0004:00:00.0: [17cb:0111] type 01 class 0x060400 PCIe Root Port
> > pci 0004:00:00.0: BAR 0 [mem 0x00000000-0x00000fff]
> > pci 0004:00:00.0: PCI bridge to [bus 01-ff]
> ...What I don't understand in these logs is how can the code changed in
> pci_read_bridge_windows() affect the lines before this line as it is being
> printed from pci_read_bridge_windows(). Maybe there are more 'PCI bridge
> to' lines above the quoted part of the dmesg?

Sorry for the confusion, the 0x100000 shift was caused by unrelated 
changes (Qcom/DWC ECAM support) and I wasn't diligent enough with which 
exact log I picked as the working one.

Here's the actual difference. Good:

❯ dmesg | rg 0004: | rg brid
[    1.780172] qcom-pcie 1c08000.pci: PCI host bridge to bus 0004:00
[    1.781930] pci 0004:00:00.0: PCI bridge to [bus 01-ff]
[    1.781972] pci 0004:00:00.0:   bridge window [io 0x100000-0x100fff]
[    1.781998] pci 0004:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
[    1.782043] pci 0004:00:00.0:   bridge window [mem 
0x00000000-0x000fffff 64bit pref]
[    1.800769] pci 0004:00:00.0: PCI bridge to [bus 01-ff]
[    1.976893] pcieport 0004:00:00.0: bridge window [mem 
0x7c400000-0x7c5fffff]: assigned

Bad:

❯ dmesg | rg 0004: | rg brid
[    1.380369] qcom-pcie 1c08000.pci: PCI host bridge to bus 0004:00
[    1.442881] pci 0004:00:00.0: PCI bridge to [bus 01-ff]
[    1.449496] pci 0004:00:00.0:   bridge window [io 0x100000-0x100fff]
[    1.462988] pci 0004:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
[    1.476661] pci 0004:00:00.0:   bridge window [mem 
0x00000000-0x000fffff 64bit pref]
[    1.502299] pci 0004:00:00.0: bridge window [mem 
0x7c300000-0x7c3fffff]: assigned
[    1.509028] pci 0004:00:00.0: bridge window [mem 
0x7c400000-0x7c4fffff 64bit pref]: assigned
[    1.509057] pci 0004:00:00.0: bridge window [io 0x100000-0x100fff]: 
assigned
[    1.509085] pci 0004:00:00.0: PCI bridge to [bus 01-ff]
[    1.509099] pci 0004:00:00.0:   bridge window [io 0x100000-0x100fff]
[    1.509124] pci 0004:00:00.0:   bridge window [mem 0x7c300000-0x7c3fffff]
[    1.509133] pci 0004:00:00.0:   bridge window [mem 
0x7c400000-0x7c4fffff 64bit pref]

I've also added log lines to pci_read_bridge_bases where the other calls 
to the same pci_read_bridge_* functions are called, and turns out they 
did *not* happen.

So it seems to me that the good reason you were wondering about for why 
the resources were not set up in pci_read_bridge_windows, is that they 
must not be set up unconditionally!

I think it's that early check in pci_read_bridge_bases that avoids the 
setup here:

    if (pci_is_root_bus(child)) /* It's a host bus, nothing to read */
        return;

Thanks,
~val