| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <f5eb0360-55bd-723c-eca2-b0f7d8971848@linux.intel.com>
Date: Mon, 6 Oct 2025 13:46:54 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Val Packett <val@...kett.cool>
cc: linux-pci@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
Krzysztof Wilczyński <kw@...ux.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Lucas De Marchi <lucas.demarchi@...el.com>
Subject: Re: [PATCH 1/2] PCI: Setup bridge resources earlier
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@...ux.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?
> pci 0004:00:00.0: bridge window [io 0x100000-0x100fff]
> pci 0004:00:00.0: bridge window [mem 0x00000000-0x000fffff]
> pci 0004:00:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref]
> pci 0004:00:00.0: PME# supported from D0 D3hot D3cold
> pci 0004:00:00.0: bridge window [mem 0x7c300000-0x7c3fffff]: assigned
> pci 0004:00:00.0: bridge window [mem 0x7c400000-0x7c4fffff 64bit pref]: assigned
> pci 0004:00:00.0: BAR 0 [mem 0x7c500000-0x7c500fff]: assigned
> pci 0004:00:00.0: bridge window [io 0x100000-0x100fff]: assigned
> pci 0004:00:00.0: PCI bridge to [bus 01-ff]
> pci 0004:00:00.0: bridge window [io 0x100000-0x100fff]
> pci 0004:00:00.0: bridge window [mem 0x7c300000-0x7c3fffff]
> pci 0004:00:00.0: bridge window [mem 0x7c400000-0x7c4fffff 64bit pref]
> pci_bus 0004:00: resource 4 [io 0x100000-0x1fffff]
> pci_bus 0004:00: resource 5 [mem 0x7c300000-0x7dffffff]
> pci_bus 0004:01: resource 0 [io 0x100000-0x100fff]
> pci_bus 0004:01: resource 1 [mem 0x7c300000-0x7c3fffff]
> pci_bus 0004:01: resource 2 [mem 0x7c400000-0x7c4fffff 64bit pref]
> pcieport 0004:00:00.0: PME: Signaling with IRQ 186
> pcieport 0004:00:00.0: AER: enabled with IRQ 186
> pci 0004:01:00.0: [17cb:1107] type 00 class 0x028000 PCIe Endpoint
> pci 0004:01:00.0: BAR 0 [mem 0x00000000-0x001fffff 64bit]
> pci 0004:01:00.0: PME# supported from D0 D3hot D3cold
> pci 0004:01:00.0: BAR 0 [mem size 0x00200000 64bit]: can't assign; no space
> pci 0004:01:00.0: BAR 0 [mem size 0x00200000 64bit]: failed to assign
> pci 0004:01:00.0: BAR 0 [mem size 0x00200000 64bit]: can't assign; no space
> pci 0004:01:00.0: BAR 0 [mem size 0x00200000 64bit]: failed to assign
> ath12k_pci 0004:01:00.0: BAR 0 [??? 0x00000000 flags 0x20000000]: can't
> assign; bogus alignment
> ath12k_pci 0004:01:00.0: failed to assign pci resource: -22
> ath12k_pci 0004:01:00.0: failed to claim device: -22
> ath12k_pci 0004:01:00.0: probe with driver ath12k_pci failed with error -22
>
>
> For comparison, with this change reverted it works again:
>
> 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 0x0000-0xfffff]
> 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]
> pci 0004:00:00.0: bridge window [io 0x0000-0x0fff]
> pci 0004:00:00.0: bridge window [mem 0x00000000-0x000fffff]
> pci 0004:00:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref]
> pci 0004:00:00.0: PME# supported from D0 D3hot D3cold
> pci 0004:00:00.0: BAR 0 [mem 0x7c300000-0x7c300fff]: assigned
> pci 0004:00:00.0: PCI bridge to [bus 01-ff]
> pci_bus 0004:00: resource 4 [io 0x0000-0xfffff]
> pci_bus 0004:00: resource 5 [mem 0x7c300000-0x7dffffff]
> pcieport 0004:00:00.0: PME: Signaling with IRQ 195
> pcieport 0004:00:00.0: AER: enabled with IRQ 195
> pci 0004:01:00.0: [17cb:1107] type 00 class 0x028000 PCIe Endpoint
> pci 0004:01:00.0: BAR 0 [mem 0x00000000-0x001fffff 64bit]
> pci 0004:01:00.0: PME# supported from D0 D3hot D3cold
> pci 0004:01:00.0: ASPM: DT platform, enabling L0s-up L0s-dw L1 ASPM-L1.1
> ASPM-L1.2 PCI-PM-L1.1 PCI-PM-L1.2
> pci 0004:01:00.0: ASPM: DT platform, enabling ClockPM
> pcieport 0004:00:00.0: bridge window [mem 0x7c400000-0x7c5fffff]: assigned
> pci 0004:01:00.0: BAR 0 [mem 0x7c400000-0x7c5fffff 64bit]: assigned
> ath12k_pci 0004:01:00.0: BAR 0 [mem 0x7c400000-0x7c5fffff 64bit]: assigned
> ath12k_pci 0004:01:00.0: enabling device (0000 -> 0002)
> ath12k_pci 0004:01:00.0: MSI vectors: 16
> ath12k_pci 0004:01:00.0: Hardware name: wcn7850 hw2.0
>
> Not quite sure what's going on with these windows..
--
i.
Powered by blists - more mailing lists