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

[Val Packett <val@packett.cool>]

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@linux.intel.com>
>> 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