[PATCH 0/2] PCI: Fix bogus resource overlaps

[PATCH 0/2] PCI: Fix bogus resource overlaps

[Ilpo Järvinen]

Hi all,

I noticed a few bogus resource overlaps in logs which occurred for PNP
resource addresses that collided with large zero-based resources
(typically IOV resources). It turns out, the problem boils down to not
marking resources properly with IORESOURCE_UNSET when BAR is read into
the struct resource.

I've long wanted to mark resource not within their window with
IORESOURCE_UNSET as done in patch 2, however, my first attempt to do it
failed because the bridge window resources were not yet available. I
assumed the bridge window change would require more extensive changes
and postponed it, but it turns there were no big complications from it
(at least so far).

But things may be more complicated than I know so if you think there's
a good reason why the filling of bridge resources is delayed to the
second read, please speak up!

There are extra notes in both patches under --- line, please check
them as well.

This series does not removed the second read of the bridge resources,
it's probably unnecessary work now but confirming that requires more
testing and code reading than I currently have time for so just sending
the obvious fix series out (and adding a TODO entry for myself for
later).

Ilpo Järvinen (2):
  PCI: Setup bridge resources earlier
  PCI: Resources outside their window must set IORESOURCE_UNSET

 drivers/pci/probe.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 3 deletions(-)


base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
-- 
2.39.5

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

[Ilpo Järvinen]

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>
---

I'm not entirely sure what is the reason why the bridge resources were
not set up by pci_read_bridge_windows(). So far I'm yet to run into any
issues because of that but perhaps there's some good reason for that
I'm not aware of?

This patch likely allows also removing pci_bridge_check_ranges() but I'm
yet to confirm that.

 drivers/pci/probe.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index f41128f91ca7..7f9da8c41620 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -524,10 +524,14 @@ static void pci_read_bridge_windows(struct pci_dev *bridge)
 	}
 	if (io) {
 		bridge->io_window = 1;
-		pci_read_bridge_io(bridge, &res, true);
+		pci_read_bridge_io(bridge,
+				   pci_resource_n(bridge, PCI_BRIDGE_IO_WINDOW),
+				   true);
 	}
 
-	pci_read_bridge_mmio(bridge, &res, true);
+	pci_read_bridge_mmio(bridge,
+			     pci_resource_n(bridge, PCI_BRIDGE_MEM_WINDOW),
+			     true);
 
 	/*
 	 * DECchip 21050 pass 2 errata: the bridge may miss an address
@@ -565,7 +569,10 @@ static void pci_read_bridge_windows(struct pci_dev *bridge)
 			bridge->pref_64_window = 1;
 	}
 
-	pci_read_bridge_mmio_pref(bridge, &res, true);
+	pci_read_bridge_mmio_pref(bridge,
+				  pci_resource_n(bridge,
+						 PCI_BRIDGE_PREF_MEM_WINDOW),
+				  true);
 }
 
 void pci_read_bridge_bases(struct pci_bus *child)
-- 
2.39.5

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

[Val Packett]

Hi,

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):

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])
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  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..

~val

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 5365 bytes --]

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?

> 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.

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@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

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 6737 bytes --]

On Mon, 6 Oct 2025, Val Packett wrote:
> 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.

Okay, I certainly couldn't figure out how that could have happened, no 
wonder then. :-)

> 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]

Interpreting these logs is usually hard even when given the whole log, it 
becomes even harder when they're filtered so that many lines of interest 
are not shown (I tried to correlate the working case to the previous 
"wrong" "correct" log but I've no guarantee the rest would remain same).

> 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;

If there's a PCI device as is the case in pci_read_bridge_windows() 
which inputs non-NULL pci_dev, the config space of that device can be read 
normally (or should be readable normally, AFAIK). The case where bus->self 
is NULL is different, we can't read from a non-existing PCI device, but 
it doesn't apply to pci_read_bridge_windows().

I don't think reading the window is the real issue here but how the 
resource fitting algorithm corners itself by reserving space for bridge 
windows before it knows their sizes, so basically these lines from the 
earlier email:

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

...which seem to occur before the child buses have been scanned so that 
space reserved is either hotplug reservation or due to "old_size" lower 
bounding. That non-prefetchable bridge window is too small to fit the 
child resources.

Could you try passing pci=hpmemsize=0M to kernel command line if that 
helps?

The other case is the "old_size" in calculate_memsize() which too can 
cause the same effect preventing sizing bridge window truly to zero when 
it's not needed (== disable it == not assign it at all at that point).
Forcing it to zero would perhaps be worth a test (or removing the max() 
related to old_size)

I've no idea why the old_size should decide anything, I hate that black 
magic but I've just not dared to remove it (it's hard to know why some 
things were made in the past, there could have been some HW issue worked 
around by such odd feature but it's so old code that there isn't any real 
information about whys anymore to find).

pci=realloc on command line might help too, but I'm not sure. There seems 
to be some extra space within the root bus resource so it might work.

I'm not sure what call chain is causing the assignment of those 3 bridge 
windows. One easy way to find out where it comes from would be to put 
WARN_ON(res->start == 0x7c400000); into pci_assign_resource() next to the 
line which prints "...: assigned".

-- 
 i.

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

[Val Packett]

On 10/7/25 12:43 PM, Ilpo Järvinen wrote:

> On Mon, 6 Oct 2025, Val Packett wrote:
>> [..]
>>
>> 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;
> If there's a PCI device as is the case in pci_read_bridge_windows()
> which inputs non-NULL pci_dev, the config space of that device can be read
> normally (or should be readable normally, AFAIK). The case where bus->self
> is NULL is different, we can't read from a non-existing PCI device, but
> it doesn't apply to pci_read_bridge_windows().
>
> I don't think reading the window is the real issue here but how the
> resource fitting algorithm corners itself by reserving space for bridge
> windows before it knows their sizes, so basically these lines from the
> earlier email:
>
> 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
>
> ...which seem to occur before the child buses have been scanned so that
> space reserved is either hotplug reservation or due to "old_size" lower
> bounding. That non-prefetchable bridge window is too small to fit the
> child resources.
>
> Could you try passing pci=hpmemsize=0M to kernel command line if that
> helps?
>
> The other case is the "old_size" in calculate_memsize() which too can
> cause the same effect preventing sizing bridge window truly to zero when
> it's not needed (== disable it == not assign it at all at that point).
> Forcing it to zero would perhaps be worth a test (or removing the max()
> related to old_size)
>
> I've no idea why the old_size should decide anything, I hate that black
> magic but I've just not dared to remove it (it's hard to know why some
> things were made in the past, there could have been some HW issue worked
> around by such odd feature but it's so old code that there isn't any real
> information about whys anymore to find).
Well, you did dare to mess with resource assignment sequence, and it got 
very quickly and quietly merged into linux-next causing a big regression 
on hardware that's not made by your company.. so maybe it's better not 
to touch anything there at all (:
> pci=realloc on command line might help too, but I'm not sure. There seems
> to be some extra space within the root bus resource so it might work.
>
> I'm not sure what call chain is causing the assignment of those 3 bridge
> windows. One easy way to find out where it comes from would be to put
> WARN_ON(res->start == 0x7c400000); into pci_assign_resource() next to the
> line which prints "...: assigned".

OK, I've uploaded the full big chungus logs (all with the WARN_ON):

https://owo.packett.cool/lin/pcifail.reverted.dmesg
https://owo.packett.cool/lin/pcifail.noarg.dmesg
https://owo.packett.cool/lin/pcifail.hpmeme.dmesg (hpmemsize didn't help)
https://owo.packett.cool/lin/pcifail.realloc.dmesg (realloc didn't help 
either)

So without your change, the assignment first comes from pci_rescan_bus → 
pci_assign_unassigned_bus_resources *via IRQ*, and then in the probe of 
the wifi driver.

~val

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 9140 bytes --]

On Thu, 9 Oct 2025, Val Packett wrote:

> On 10/7/25 12:43 PM, Ilpo Järvinen wrote:
> 
> > On Mon, 6 Oct 2025, Val Packett wrote:
> > > [..]
> > > 
> > > 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;
> > If there's a PCI device as is the case in pci_read_bridge_windows()
> > which inputs non-NULL pci_dev, the config space of that device can be read
> > normally (or should be readable normally, AFAIK). The case where bus->self
> > is NULL is different, we can't read from a non-existing PCI device, but
> > it doesn't apply to pci_read_bridge_windows().
> > 
> > I don't think reading the window is the real issue here but how the
> > resource fitting algorithm corners itself by reserving space for bridge
> > windows before it knows their sizes, so basically these lines from the
> > earlier email:
> > 
> > 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
> > 
> > ...which seem to occur before the child buses have been scanned so that
> > space reserved is either hotplug reservation or due to "old_size" lower
> > bounding. That non-prefetchable bridge window is too small to fit the
> > child resources.
> > 
> > Could you try passing pci=hpmemsize=0M to kernel command line if that
> > helps?
> > 
> > The other case is the "old_size" in calculate_memsize() which too can
> > cause the same effect preventing sizing bridge window truly to zero when
> > it's not needed (== disable it == not assign it at all at that point).
> > Forcing it to zero would perhaps be worth a test (or removing the max()
> > related to old_size)
> > 
> > I've no idea why the old_size should decide anything, I hate that black
> > magic but I've just not dared to remove it (it's hard to know why some
> > things were made in the past, there could have been some HW issue worked
> > around by such odd feature but it's so old code that there isn't any real
> > information about whys anymore to find).
>
> Well, you did dare to mess with resource assignment sequence, and it got very
> quickly and quietly merged into linux-next causing a big regression on
> hardware that's not made by your company.. so maybe it's better not to touch
> anything there at all (:

Even if you were very likely joking here, I'm still sorry for breaking it, 
no matter which company's device.

Perhaps I'll start Cc you in all upcoming resource changes as you seem to 
be so willing to volunteer to review them. ;-D

> > pci=realloc on command line might help too, but I'm not sure. There seems
> > to be some extra space within the root bus resource so it might work.
> > 
> > I'm not sure what call chain is causing the assignment of those 3 bridge
> > windows. One easy way to find out where it comes from would be to put
> > WARN_ON(res->start == 0x7c400000); into pci_assign_resource() next to the
> > line which prints "...: assigned".
> 
> OK, I've uploaded the full big chungus logs (all with the WARN_ON):
> 
> https://owo.packett.cool/lin/pcifail.reverted.dmesg
> https://owo.packett.cool/lin/pcifail.noarg.dmesg
> https://owo.packett.cool/lin/pcifail.hpmeme.dmesg (hpmemsize didn't help)
> https://owo.packett.cool/lin/pcifail.realloc.dmesg (realloc didn't help
> either)

Thanks for the logs.

> So without your change, the assignment first comes from pci_rescan_bus →
> pci_assign_unassigned_bus_resources *via IRQ*, and then in the probe of the
> wifi driver.

There seem to be cases where pci_assign_unassigned_root_bus_resources() 
executes for bus 0000:04 before 0004:01:00.0 is scanned as it is only 
recorded later.

Hmm, qcom_pcie_global_irq_thread() seems to indicate the real enumeration 
can only occur after the link up event has arrived, and it starts another 
scan from there.

Perhaps this could be solved by inhibiting resource sizing and assignment 
per host bridge until the bus could be enumerated for real. Otherwise the 
resource assignment has no idea how the bridge windows should be sized 
which then can lead to this cornering itself if the initial assignment 
without knowledge of the necessary sizes.

Could you please try if the patch below helps?


--
From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
Date: Fri, 10 Oct 2025 19:55:49 +0300
Subject: [PATCH 1/1] PCI: Delay resource sizing until devices can be enumerated
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It seems pci-qcom cannot yet enumerate devices while scanning bus from
pci_host_probe(). Instead, there is IRQ waiting for a link up event
which starts the scan from qcom_pcie_global_irq_thread().

pci_host_probe() also calls pci_assign_unassigned_root_bus_resources()
which tries to size the bridge windows without any knowledge about the
attached devices and assigns them. If the assigned window is too small
to accomodate all the devices resource once they appear, the windows
may have become so pinned in place that they cannot be successfully
resized.

It is not very useful to size bridge windows without the children.
Thus, mark into the struct pci_host_bridge that delayed enumeration is
performed. Inhibit resource assignment until the enumeration is known
to be possible.

FIXME: There could be other entrypoints to resource assignment code
beyond those that include check for ->enumeration_pending but these
were the ones seen in the logs.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
 drivers/pci/controller/dwc/pcie-qcom.c |  3 +++
 drivers/pci/setup-bus.c                | 10 ++++++++++
 include/linux/pci.h                    |  1 +
 3 files changed, 14 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 294babe1816e..33683d751de0 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -1644,6 +1644,7 @@ static irqreturn_t qcom_pcie_global_irq_thread(int irq, void *data)
 		msleep(PCIE_RESET_CONFIG_WAIT_MS);
 		dev_dbg(dev, "Received Link up event. Starting enumeration!\n");
 		/* Rescan the bus to enumerate endpoint devices */
+		pp->bridge->enumeration_pending = 0;
 		pci_lock_rescan_remove();
 		pci_rescan_bus(pp->bridge->bus);
 		pci_unlock_rescan_remove();
@@ -1825,6 +1826,8 @@ static int qcom_pcie_probe(struct platform_device *pdev)
 		bridge->sysdata = cfg;
 		bridge->ops = (struct pci_ops *)&pci_qcom_ecam_ops.pci_ops;
 		bridge->msi_domain = true;
+		// FIXME: Should this be specific to just some host bridges?
+		bridge->enumeration_pending = 1;
 
 		ret = pci_host_probe(bridge);
 		if (ret)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7853ac6999e2..a54a4dda6b60 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -2266,6 +2266,7 @@ static void pci_prepare_next_assign_round(struct list_head *fail_head,
  */
 void pci_assign_unassigned_root_bus_resources(struct pci_bus *bus)
 {
+	struct pci_host_bridge *host = pci_find_host_bridge(bus);
 	LIST_HEAD(realloc_head);
 	/* List of resources that want additional resources */
 	struct list_head *add_list = NULL;
@@ -2275,6 +2276,10 @@ void pci_assign_unassigned_root_bus_resources(struct pci_bus *bus)
 	int pci_try_num = 1;
 	enum enable_type enable_local;
 
+	/* Wait until enumeration to avoid pinning windows with wrong sizes. */
+	if (host->enumeration_pending)
+		return;
+
 	/* Don't realloc if asked to do so */
 	enable_local = pci_realloc_detect(bus, pci_realloc_enable);
 	if (pci_realloc_enabled(enable_local)) {
@@ -2489,10 +2494,15 @@ int pci_reassign_bridge_resources(struct pci_dev *bridge, unsigned long type)
 
 void pci_assign_unassigned_bus_resources(struct pci_bus *bus)
 {
+	struct pci_host_bridge *host = pci_find_host_bridge(bus);
 	struct pci_dev *dev;
 	/* List of resources that want additional resources */
 	LIST_HEAD(add_list);
 
+	/* Wait until enumeration to avoid pinning windows with wrong sizes. */
+	if (host->enumeration_pending)
+		return;
+
 	down_read(&pci_bus_sem);
 	for_each_pci_bridge(dev, bus)
 		if (pci_has_subordinate(dev))
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 59876de13860..10fb5aaecd8e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -619,6 +619,7 @@ struct pci_host_bridge {
 	unsigned int	preserve_config:1;	/* Preserve FW resource setup */
 	unsigned int	size_windows:1;		/* Enable root bus sizing */
 	unsigned int	msi_domain:1;		/* Bridge wants MSI domain */
+	unsigned int	enumeration_pending:1;	/* Delayed enumeration */
 
 	/* Resource alignment requirements */
 	resource_size_t (*align_resource)(struct pci_dev *dev,

base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
-- 
2.39.5

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

[Val Packett]

On 10/10/25 2:01 PM, Ilpo Järvinen wrote:

> [..]
> Even if you were very likely joking here, I'm still sorry for breaking it,
> no matter which company's device.
>
> Perhaps I'll start Cc you in all upcoming resource changes as you seem to
> be so willing to volunteer to review them. ;-D

Perhaps Intel corporate could pay me for QAing the patches :D

> There seem to be cases where pci_assign_unassigned_root_bus_resources()
> executes for bus 0000:04 before 0004:01:00.0 is scanned as it is only
> recorded later.
>
> Hmm, qcom_pcie_global_irq_thread() seems to indicate the real enumeration
> can only occur after the link up event has arrived, and it starts another
> scan from there.

Right, I've even seen things about the link-up sequence in the commits 
for the PCIe driver, e.g. 4581403f6792 ("PCI: qcom: Enumerate endpoints 
based on Link up event in 'global_irq' interrupt").

Is this really that uncommon? Can we be sure that other drivers don't 
behave similarly?

> Perhaps this could be solved by inhibiting resource sizing and assignment
> per host bridge until the bus could be enumerated for real. Otherwise the
> resource assignment has no idea how the bridge windows should be sized
> which then can lead to this cornering itself if the initial assignment
> without knowledge of the necessary sizes.
>
> Could you please try if the patch below helps?
> [..]
> @@ -1825,6 +1826,8 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>   		bridge->sysdata = cfg;
>   		bridge->ops = (struct pci_ops *)&pci_qcom_ecam_ops.pci_ops;
>   		bridge->msi_domain = true;
> +		// FIXME: Should this be specific to just some host bridges?
> +		bridge->enumeration_pending = 1;
>   
>   		ret = pci_host_probe(bridge);
>   		if (ret)

..and nope, particularly that assignment did not run because at least on 
x1e, the bridges are not firmware_managed, so they are enumerated normally.

~val

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

[Manivannan Sadhasivam]

On Tue, Oct 07, 2025 at 06:43:03PM +0300, Ilpo Järvinen wrote:
> On Mon, 6 Oct 2025, Val Packett wrote:
> > 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.
> 
> Okay, I certainly couldn't figure out how that could have happened, no 
> wonder then. :-)
> 
> > 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]
> 
> Interpreting these logs is usually hard even when given the whole log, it 
> becomes even harder when they're filtered so that many lines of interest 
> are not shown (I tried to correlate the working case to the previous 
> "wrong" "correct" log but I've no guarantee the rest would remain same).
> 
> > 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;
> 
> If there's a PCI device as is the case in pci_read_bridge_windows() 
> which inputs non-NULL pci_dev, the config space of that device can be read 
> normally (or should be readable normally, AFAIK). The case where bus->self 
> is NULL is different, we can't read from a non-existing PCI device, but 
> it doesn't apply to pci_read_bridge_windows().
> 
> I don't think reading the window is the real issue here but how the 
> resource fitting algorithm corners itself by reserving space for bridge 
> windows before it knows their sizes, so basically these lines from the 
> earlier email:
> 
> 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
> 
> ...which seem to occur before the child buses have been scanned so that 
> space reserved is either hotplug reservation or due to "old_size" lower 
> bounding. That non-prefetchable bridge window is too small to fit the 
> child resources.
> 

Yeah, this is specifically the reason why the issue only affects the WiFi card
and not NVMe on this platform. The NVMe is powered on by the bootloader/BIOS
and it doesn't use the pwrctrl framework to handle the power management. But on
the other hand, the WiFi is not powered on by the bootloader and powered on by
the pwrctrl framework (which happens after the bridge windows are allocated).
Since the Root Port is not hotplug capable, the initial bridge window assigned
is not enough for the WiFi card that comes up later and hence the failure.

This also rings a bell that I should change the way the pwrctrl framework power
on the devices. I think the devices/slot should be powered on before scanning
the secondary bus of the Root Port so that the resource fitting algorithm knows
how much bridge window memory should be allocated.

I did notice the similar issue while trying to use the pwrctrl framework to
power on an endpoint connected to a PCIe switch. But your patch made it obvious
that the issue gets triggered even for the endpoints connected to the Root
Port. I didn't digged into this issue yet, but this is the theory I came up
with.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Bjorn Helgaas]

[+cc Guenter, regressions]

On Mon, Oct 06, 2025 at 05:00:25AM -0300, 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):
> 
> 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])
> 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  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

#regzbot introduced: a43ac325c7cb ("PCI: Set up bridge resources earlier")

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

[Bjorn Helgaas]

On Mon, Oct 13, 2025 at 04:01:16PM -0500, Bjorn Helgaas wrote:
> On Mon, Oct 06, 2025 at 05:00:25AM -0300, 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):
> ...

> #regzbot introduced: a43ac325c7cb ("PCI: Set up bridge resources earlier")
#regzbot fix: 469276c06aff ("PCI: Revert early bridge resource set up")

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

[Bjorn Helgaas]

On Tue, Oct 28, 2025 at 05:47:58PM -0500, Bjorn Helgaas wrote:
> On Mon, Oct 13, 2025 at 04:01:16PM -0500, Bjorn Helgaas wrote:
> > On Mon, Oct 06, 2025 at 05:00:25AM -0300, 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):
> > ...
> 
> > #regzbot introduced: a43ac325c7cb ("PCI: Set up bridge resources earlier")
> #regzbot fix: 469276c06aff ("PCI: Revert early bridge resource set up")

TIL that "#regzbot fix:" should include only the SHA1, not the commit
subject.

Also I think I should have used "#regzbot report:" to point to Val and
Guenter's original reports instead of "#regzbot introduced:".

#regzbot report: https://lore.kernel.org/r/017ff8df-511c-4da8-b3cf-edf2cb7f1a67@packett.cool
#regzbot report: https://lore.kernel.org/r/df266709-a9b3-4fd8-af3a-c22eb3c9523a@roeck-us.net
#regzbot fix: 469276c06aff

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

[Guenter Roeck]

Hi,

On Wed, Sep 24, 2025 at 04:42:27PM +0300, 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>
> ---

This patch causes some boot test failures for me. Specifically, booting
alpha images from PCI through a PCI bridge fails. Reverting it fixes
the problem.

Bisect log attached for reference.

Guenter

---
# bad: [3a8660878839faadb4f1a6dd72c3179c1df56787] Linux 6.18-rc1
# good: [e5f0a698b34ed76002dc5cff3804a61c80233a7a] Linux 6.17
git bisect start 'HEAD' 'v6.17'
# good: [58809f614e0e3f4e12b489bddf680bfeb31c0a20] Merge tag 'drm-next-2025-10-01' of https://gitlab.freedesktop.org/drm/kernel
git bisect good 58809f614e0e3f4e12b489bddf680bfeb31c0a20
# good: [bed0653fe2aacb0ca8196075cffc9e7062e74927] Merge tag 'iommu-updates-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux
git bisect good bed0653fe2aacb0ca8196075cffc9e7062e74927
# good: [6a74422b9710e987c7d6b85a1ade7330b1e61626] Merge tag 'mips_6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
git bisect good 6a74422b9710e987c7d6b85a1ade7330b1e61626
# bad: [522ba450b56fff29f868b1552bdc2965f55de7ed] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
git bisect bad 522ba450b56fff29f868b1552bdc2965f55de7ed
# bad: [256e3417065b2721f77bcd37331796b59483ef3b] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect bad 256e3417065b2721f77bcd37331796b59483ef3b
# bad: [2f2c7254931f41b5736e3ba12aaa9ac1bbeeeb92] Merge tag 'pci-v6.18-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
git bisect bad 2f2c7254931f41b5736e3ba12aaa9ac1bbeeeb92
# bad: [531abff0fa53bc3a2f7f69b2693386eb6bda96e5] Merge branch 'pci/controller/qcom'
git bisect bad 531abff0fa53bc3a2f7f69b2693386eb6bda96e5
# bad: [fead6a0b15bf3b33dba877efec6b4e7b4cc4abc3] Merge branch 'pci/resource'
git bisect bad fead6a0b15bf3b33dba877efec6b4e7b4cc4abc3
# good: [0bb65e32495e6235a069b60e787140da99e9c122] Merge branch 'pci/p2pdma'
git bisect good 0bb65e32495e6235a069b60e787140da99e9c122
# good: [ebe091ad81e1d3e5cbb1592ebc18175b5ca3d2bd] PCI: Use pbus_select_window_for_type() during IO window sizing
git bisect good ebe091ad81e1d3e5cbb1592ebc18175b5ca3d2bd
# good: [15c5867b0ae6a47914b45daf3b64e2d2aceb4ee5] PCI: Don't print stale information about resource
git bisect good 15c5867b0ae6a47914b45daf3b64e2d2aceb4ee5
# good: [dc32e9346b26ba33e84ec3034a1e53a9733700f9] PCI/pwrctrl: Fix device leak at device stop
git bisect good dc32e9346b26ba33e84ec3034a1e53a9733700f9
# good: [4c5cd8d64172de3730056366dc61392a3f2f003a] Merge branch 'pci/pm'
git bisect good 4c5cd8d64172de3730056366dc61392a3f2f003a
# bad: [a43ac325c7cbbfe72bdf9178059b3ee9f5a2c7dd] PCI: Set up bridge resources earlier
git bisect bad a43ac325c7cbbfe72bdf9178059b3ee9f5a2c7dd
# first bad commit: [a43ac325c7cbbfe72bdf9178059b3ee9f5a2c7dd] PCI: Set up bridge resources earlier

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 3937 bytes --]

On Mon, 13 Oct 2025, Guenter Roeck wrote:
> On Wed, Sep 24, 2025 at 04:42:27PM +0300, 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>
> > ---
> 
> This patch causes some boot test failures for me. Specifically, booting
> alpha images from PCI through a PCI bridge fails. Reverting it fixes
> the problem.
> 
> Bisect log attached for reference.
> 
> Guenter
> 
> ---
> # bad: [3a8660878839faadb4f1a6dd72c3179c1df56787] Linux 6.18-rc1
> # good: [e5f0a698b34ed76002dc5cff3804a61c80233a7a] Linux 6.17
> git bisect start 'HEAD' 'v6.17'
> # good: [58809f614e0e3f4e12b489bddf680bfeb31c0a20] Merge tag 'drm-next-2025-10-01' of https://gitlab.freedesktop.org/drm/kernel
> git bisect good 58809f614e0e3f4e12b489bddf680bfeb31c0a20
> # good: [bed0653fe2aacb0ca8196075cffc9e7062e74927] Merge tag 'iommu-updates-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux
> git bisect good bed0653fe2aacb0ca8196075cffc9e7062e74927
> # good: [6a74422b9710e987c7d6b85a1ade7330b1e61626] Merge tag 'mips_6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
> git bisect good 6a74422b9710e987c7d6b85a1ade7330b1e61626
> # bad: [522ba450b56fff29f868b1552bdc2965f55de7ed] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> git bisect bad 522ba450b56fff29f868b1552bdc2965f55de7ed
> # bad: [256e3417065b2721f77bcd37331796b59483ef3b] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
> git bisect bad 256e3417065b2721f77bcd37331796b59483ef3b
> # bad: [2f2c7254931f41b5736e3ba12aaa9ac1bbeeeb92] Merge tag 'pci-v6.18-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
> git bisect bad 2f2c7254931f41b5736e3ba12aaa9ac1bbeeeb92
> # bad: [531abff0fa53bc3a2f7f69b2693386eb6bda96e5] Merge branch 'pci/controller/qcom'
> git bisect bad 531abff0fa53bc3a2f7f69b2693386eb6bda96e5
> # bad: [fead6a0b15bf3b33dba877efec6b4e7b4cc4abc3] Merge branch 'pci/resource'
> git bisect bad fead6a0b15bf3b33dba877efec6b4e7b4cc4abc3
> # good: [0bb65e32495e6235a069b60e787140da99e9c122] Merge branch 'pci/p2pdma'
> git bisect good 0bb65e32495e6235a069b60e787140da99e9c122
> # good: [ebe091ad81e1d3e5cbb1592ebc18175b5ca3d2bd] PCI: Use pbus_select_window_for_type() during IO window sizing
> git bisect good ebe091ad81e1d3e5cbb1592ebc18175b5ca3d2bd
> # good: [15c5867b0ae6a47914b45daf3b64e2d2aceb4ee5] PCI: Don't print stale information about resource
> git bisect good 15c5867b0ae6a47914b45daf3b64e2d2aceb4ee5
> # good: [dc32e9346b26ba33e84ec3034a1e53a9733700f9] PCI/pwrctrl: Fix device leak at device stop
> git bisect good dc32e9346b26ba33e84ec3034a1e53a9733700f9
> # good: [4c5cd8d64172de3730056366dc61392a3f2f003a] Merge branch 'pci/pm'
> git bisect good 4c5cd8d64172de3730056366dc61392a3f2f003a
> # bad: [a43ac325c7cbbfe72bdf9178059b3ee9f5a2c7dd] PCI: Set up bridge resources earlier
> git bisect bad a43ac325c7cbbfe72bdf9178059b3ee9f5a2c7dd
> # first bad commit: [a43ac325c7cbbfe72bdf9178059b3ee9f5a2c7dd] PCI: Set up bridge resources earlier

Hi,

Is it possible to get some logs from this (both good and bad would be 
the best so comparing is possible)?

I'm going to send a revert for the commit a43ac325c7cb ("PCI: Set up 
bridge resources earlier") today anyway because of another issue it caused
but as I'm planning to pursue the same change later, it would be useful to 
understand what goes wrong here so I know what additional supporting work 
is needed before coming back with this change.

-- 
 i.

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

[Bhanu Seshu Kumar Valluri]

Hi,

I want to report that this PATCH also break PCI RC port on TI-AM64-EVM.

I did git bisect and it pointed to the a43ac325c7cb ("PCI: Set up bridge resources earlier")

Happy to help if any testing or logs are required.



echo 1 > /sys/bus/pci/rescan
[   37.170389] pci 0000:01:00.0: [104c:b010] type 00 class 0xff0000 PCIe Endpoint
[   37.177781] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x0000ffff]
[   37.183808] pci 0000:01:00.0: BAR 1 [mem 0x00000000-0x000001ff]
[   37.189843] pci 0000:01:00.0: BAR 2 [mem 0x00000000-0x000003ff]
[   37.195802] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x00003fff]
[   37.201768] pci 0000:01:00.0: BAR 4 [mem 0x00000000-0x0001ffff]
[   37.207715] pci 0000:01:00.0: BAR 5 [mem 0x00000000-0x000fffff]
[   37.214040] pci 0000:01:00.0: supports D1
[   37.218083] pci 0000:01:00.0: PME# supported from D0 D1 D3hot
[   37.231890] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: assigned
[   37.242890] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: can't assign; no space
[   37.251216] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: failed to assign
[   37.258309] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: can't assign; no space
[   37.265851] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: failed to assign
[   37.272896] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: can't assign; no space
[   37.280439] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: failed to assign
[   37.287459] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: can't assign; no space
[   37.294986] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: failed to assign
[   37.302011] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: can't assign; no space
[   37.309536] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: failed to assign
[   37.316595] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: releasing
[   37.323541] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: assigned
[   37.330400] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: can't assign; no space
[   37.337956] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: failed to assign
[   37.344960] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: can't assign; no space
[   37.352550] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: failed to assign
[   37.359578] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: can't assign; no space
[   37.367152] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: failed to assign
[   37.374192] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: can't assign; no space
[   37.381709] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: failed to assign
[   37.388720] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: can't assign; no space
[   37.396246] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: failed to assign
[   37.403795] pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22
[   37.410513] pci-endpoint-test 0000:01:00.0: enabling device (0000 -> 0002)
[   37.417796] pci-endpoint-test 0000:01:00.0: Cannot perform PCI test without BAR0


Regards,
Bhanu Seshu Kumar Valluri

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

[Bhanu Seshu Kumar Valluri]

On 17/10/25 23:52, Bhanu Seshu Kumar Valluri wrote:
> Hi,
> 
> I want to report that this PATCH also break PCI RC port on TI-AM64-EVM.
> 
> I did git bisect and it pointed to the a43ac325c7cb ("PCI: Set up bridge resources earlier")
> 
> Happy to help if any testing or logs are required.
> 
> 
> 
> echo 1 > /sys/bus/pci/rescan
> [   37.170389] pci 0000:01:00.0: [104c:b010] type 00 class 0xff0000 PCIe Endpoint
> [   37.177781] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x0000ffff]
> [   37.183808] pci 0000:01:00.0: BAR 1 [mem 0x00000000-0x000001ff]
> [   37.189843] pci 0000:01:00.0: BAR 2 [mem 0x00000000-0x000003ff]
> [   37.195802] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x00003fff]
> [   37.201768] pci 0000:01:00.0: BAR 4 [mem 0x00000000-0x0001ffff]
> [   37.207715] pci 0000:01:00.0: BAR 5 [mem 0x00000000-0x000fffff]
> [   37.214040] pci 0000:01:00.0: supports D1
> [   37.218083] pci 0000:01:00.0: PME# supported from D0 D1 D3hot
> [   37.231890] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: assigned
> [   37.242890] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: can't assign; no space
> [   37.251216] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: failed to assign
> [   37.258309] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: can't assign; no space
> [   37.265851] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: failed to assign
> [   37.272896] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: can't assign; no space
> [   37.280439] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: failed to assign
> [   37.287459] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: can't assign; no space
> [   37.294986] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: failed to assign
> [   37.302011] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: can't assign; no space
> [   37.309536] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: failed to assign
> [   37.316595] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: releasing
> [   37.323541] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: assigned
> [   37.330400] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: can't assign; no space
> [   37.337956] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: failed to assign
> [   37.344960] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: can't assign; no space
> [   37.352550] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: failed to assign
> [   37.359578] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: can't assign; no space
> [   37.367152] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: failed to assign
> [   37.374192] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: can't assign; no space
> [   37.381709] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: failed to assign
> [   37.388720] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: can't assign; no space
> [   37.396246] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: failed to assign
> [   37.403795] pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22
> [   37.410513] pci-endpoint-test 0000:01:00.0: enabling device (0000 -> 0002)
> [   37.417796] pci-endpoint-test 0000:01:00.0: Cannot perform PCI test without BAR0
> 

In my setup is pci topology very simple. Just two TI-AM64-EVM directly connected to one another.
One acts as RC and the other is EP.

Regards,
Bhanu Seshu Kumar Valluri

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

[Bjorn Helgaas]

On Fri, Oct 17, 2025 at 11:52:58PM +0530, Bhanu Seshu Kumar Valluri wrote:
> Hi,
> 
> I want to report that this PATCH also break PCI RC port on TI-AM64-EVM.
> 
> I did git bisect and it pointed to the a43ac325c7cb ("PCI: Set up bridge resources earlier")
> 
> Happy to help if any testing or logs are required.

Thanks for the report!  Can you test this patch?

  https://patch.msgid.link/20251014163602.17138-1-ilpo.jarvinen@linux.intel.com

That patch is queued up as
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?id=469276c06aff
and should appear in v6.18-rc2 on Sunday if all goes well.

If that doesn't work, let us know and we'll debug this further.

> echo 1 > /sys/bus/pci/rescan
> [   37.170389] pci 0000:01:00.0: [104c:b010] type 00 class 0xff0000 PCIe Endpoint
> [   37.177781] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x0000ffff]
> [   37.183808] pci 0000:01:00.0: BAR 1 [mem 0x00000000-0x000001ff]
> [   37.189843] pci 0000:01:00.0: BAR 2 [mem 0x00000000-0x000003ff]
> [   37.195802] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x00003fff]
> [   37.201768] pci 0000:01:00.0: BAR 4 [mem 0x00000000-0x0001ffff]
> [   37.207715] pci 0000:01:00.0: BAR 5 [mem 0x00000000-0x000fffff]
> [   37.214040] pci 0000:01:00.0: supports D1
> [   37.218083] pci 0000:01:00.0: PME# supported from D0 D1 D3hot
> [   37.231890] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: assigned
> [   37.242890] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: can't assign; no space
> [   37.251216] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: failed to assign
> [   37.258309] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: can't assign; no space
> [   37.265851] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: failed to assign
> [   37.272896] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: can't assign; no space
> [   37.280439] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: failed to assign
> [   37.287459] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: can't assign; no space
> [   37.294986] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: failed to assign
> [   37.302011] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: can't assign; no space
> [   37.309536] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: failed to assign
> [   37.316595] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: releasing
> [   37.323541] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: assigned
> [   37.330400] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: can't assign; no space
> [   37.337956] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: failed to assign
> [   37.344960] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: can't assign; no space
> [   37.352550] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: failed to assign
> [   37.359578] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: can't assign; no space
> [   37.367152] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: failed to assign
> [   37.374192] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: can't assign; no space
> [   37.381709] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: failed to assign
> [   37.388720] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: can't assign; no space
> [   37.396246] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: failed to assign
> [   37.403795] pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22
> [   37.410513] pci-endpoint-test 0000:01:00.0: enabling device (0000 -> 0002)
> [   37.417796] pci-endpoint-test 0000:01:00.0: Cannot perform PCI test without BAR0
> 
> 
> Regards,
> Bhanu Seshu Kumar Valluri

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

[Bhanu Seshu Kumar Valluri]

On 18/10/25 00:22, Bjorn Helgaas wrote:
> On Fri, Oct 17, 2025 at 11:52:58PM +0530, Bhanu Seshu Kumar Valluri wrote:
>> Hi,
>>
>> I want to report that this PATCH also break PCI RC port on TI-AM64-EVM.
>>
>> I did git bisect and it pointed to the a43ac325c7cb ("PCI: Set up bridge resources earlier")
>>
>> Happy to help if any testing or logs are required.
> 
> Thanks for the report!  Can you test this patch?
> 
>   https://patch.msgid.link/20251014163602.17138-1-ilpo.jarvinen@linux.intel.com
> 
> That patch is queued up as
> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?id=469276c06aff
> and should appear in v6.18-rc2 on Sunday if all goes well.
> 
> If that doesn't work, let us know and we'll debug this further.

I applied above patch on top of commit f406055cb18c ("Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux")

Did pci rescan and run kselftest (pci_endpoint_test). It is working.

Thanks for the patch.

Happy to help if any testing or logs are required.

[logs are as pasted below]

root@am64xx-evm:~# echo 1 > /sys/bus/pci/rescan
[   37.938991] pci 0000:01:00.0: [104c:b010] type 00 class 0xff0000 PCIe Endpoint
[   37.946384] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x0000ffff]
[   37.952430] pci 0000:01:00.0: BAR 1 [mem 0x00000000-0x000001ff]
[   37.958471] pci 0000:01:00.0: BAR 2 [mem 0x00000000-0x000003ff]
[   37.964499] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x00003fff]
[   37.970601] pci 0000:01:00.0: BAR 4 [mem 0x00000000-0x0001ffff]
[   37.976673] pci 0000:01:00.0: BAR 5 [mem 0x00000000-0x000fffff]
[   37.983157] pci 0000:01:00.0: supports D1
[   37.987241] pci 0000:01:00.0: PME# supported from D0 D1 D3hot
[   37.999527] pci 0000: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
[   38.010392] pci 0000:01:00.0: ASPM: DT platform, enabling ClockPM
[   38.016760] pcieport 0000:00:00.0: bridge window [mem 0x68100000-0x682fffff]: assigned
[   38.024940] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: assigned
[   38.031906] pci 0000:01:00.0: BAR 4 [mem 0x68200000-0x6821ffff]: assigned
[   38.038769] pci 0000:01:00.0: BAR 0 [mem 0x68220000-0x6822ffff]: assigned
[   38.045849] pci 0000:01:00.0: BAR 3 [mem 0x68230000-0x68233fff]: assigned
[   38.052804] pci 0000:01:00.0: BAR 2 [mem 0x68234000-0x682343ff]: assigned
[   38.059832] pci 0000:01:00.0: BAR 1 [mem 0x68234400-0x682345ff]: assigned
[   38.067507] pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22
[   38.074329] pci-endpoint-test 0000:01:00.0: enabling device (0000 -> 0002)

--------------------------------------------------------------------------------------------------------

root@am64xx-evm:~# ./pci_endpoint_test -T LEGACY_IRQ_TEST
TAP version 13
1..16
# Starting 16 tests from 10 test cases.
#  RUN           pci_ep_bar.BAR0.BAR_TEST ...
#            OK  pci_ep_bar.BAR0.BAR_TEST
ok 1 pci_ep_bar.BAR0.BAR_TEST
#  RUN           pci_ep_bar.BAR1.BAR_TEST ...
#            OK  pci_ep_bar.BAR1.BAR_TEST
ok 2 pci_ep_bar.BAR1.BAR_TEST
#  RUN           pci_ep_bar.BAR2.BAR_TEST ...
#            OK  pci_ep_bar.BAR2.BAR_TEST
ok 3 pci_ep_bar.BAR2.BAR_TEST
#  RUN           pci_ep_bar.BAR3.BAR_TEST ...
#            OK  pci_ep_bar.BAR3.BAR_TEST
ok 4 pci_ep_bar.BAR3.BAR_TEST
#  RUN           pci_ep_bar.BAR4.BAR_TEST ...
#            OK  pci_ep_bar.BAR4.BAR_TEST
ok 5 pci_ep_bar.BAR4.BAR_TEST
#  RUN           pci_ep_bar.BAR5.BAR_TEST ...
#            OK  pci_ep_bar.BAR5.BAR_TEST
ok 6 pci_ep_bar.BAR5.BAR_TEST
#  RUN           pci_ep_basic.CONSECUTIVE_BAR_TEST ...
#            OK  pci_ep_basic.CONSECUTIVE_BAR_TEST
ok 7 pci_ep_basic.CONSECUTIVE_BAR_TEST
#  RUN           pci_ep_basic.MSI_TEST ...
#            OK  pci_ep_basic.MSI_TEST
ok 8 pci_ep_basic.MSI_TEST
#  RUN           pci_ep_basic.MSIX_TEST ...
#            OK  pci_ep_basic.MSIX_TEST
ok 9 pci_ep_basic.MSIX_TEST
#  RUN           pci_ep_data_transfer.memcpy.READ_TEST ...
#            OK  pci_ep_data_transfer.memcpy.READ_TEST
ok 10 pci_ep_data_transfer.memcpy.READ_TEST
#  RUN           pci_ep_data_transfer.memcpy.WRITE_TEST ...
#            OK  pci_ep_data_transfer.memcpy.WRITE_TEST
ok 11 pci_ep_data_transfer.memcpy.WRITE_TEST
#  RUN           pci_ep_data_transfer.memcpy.COPY_TEST ...
#            OK  pci_ep_data_transfer.memcpy.COPY_TEST
ok 12 pci_ep_data_transfer.memcpy.COPY_TEST
#  RUN           pci_ep_data_transfer.dma.READ_TEST ...
#            OK  pci_ep_data_transfer.dma.READ_TEST
ok 13 pci_ep_data_transfer.dma.READ_TEST
#  RUN           pci_ep_data_transfer.dma.WRITE_TEST ...
#            OK  pci_ep_data_transfer.dma.WRITE_TEST
ok 14 pci_ep_data_transfer.dma.WRITE_TEST
#  RUN           pci_ep_data_transfer.dma.COPY_TEST ...
#            OK  pci_ep_data_transfer.dma.COPY_TEST
ok 15 pci_ep_data_transfer.dma.COPY_TEST
#  RUN           pcie_ep_doorbell.DOORBELL_TEST ...
#            OK  pcie_ep_doorbell.DOORBELL_TEST
ok 16 pcie_ep_doorbell.DOORBELL_TEST
# PASSED: 16 / 16 tests passed.
# Totals: pass:16 fail:0 xfail:0 xpass:0 skip:0 error:0

------------------------------------------------------------------------------------------

root@am64xx-evm:~# lspci -vv
00:00.0 PCI bridge: Texas Instruments Device b010 (prog-if 00 [Normal decode])
        Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 506
        Region 0: Memory at <unassigned> (64-bit, prefetchable) [disabled]
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: [disabled]
        Memory behind bridge: [disabled]
        Prefetchable memory behind bridge: [disabled]
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: [80] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable+ 64bit+
                Address: 0000000001000000  Data: 0000
                Masking: 00000000  Pending: 00000000
        Capabilities: [b0] MSI-X: Enable- Count=1 Masked-
                Vector table: BAR=0 offset=00000000
                PBA: BAR=0 offset=00000008
        Capabilities: [c0] Express (v2) Root Port (Slot+), MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0
                        ExtTag- RBE+
                DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L1, Exit Latency L1 <8us
                        ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt+ AutBWInt+
                LnkSta: Speed 5GT/s (ok), Width x1 (ok)
                        TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt+
                SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
                        Slot #0, PowerLimit 0.000W; Interlock- NoCompl-
                SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
                        Control: AttnInd Off, PwrInd Off, Power+ Interlock-
                SltSta: Status: AttnBtn- PowerFlt- MRL+ CmdCplt- PresDet- Interlock-
                        Changed: MRL- PresDet- LinkState-
                RootCap: CRSVisible-
                RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
                RootSta: PME ReqID 0000, PMEStatus- PMEPending-
                DevCap2: Completion Timeout: Range B, TimeoutDis+ NROPrPrP- LTR+
                         10BitTagComp- 10BitTagReq- OBFF Via message, ExtFmt+ EETLPPrefix+, MaxEETLPPrefixes 1
                         EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
                         FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- ARIFwd-
                         AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ OBFF Disabled, ARIFwd-
                         AtomicOpsCtl: ReqEn- EgressBlck-
                LnkCap2: Supported Link Speeds: 2.5-5GT/s, Crosslink- Retimer- 2Retimers- DRS-
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
                         EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
                         Retimer- 2Retimers- CrosslinkRes: unsupported
        Capabilities: [100 v2] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
                HeaderLog: 00000000 00000000 00000000 00000000
                RootCmd: CERptEn+ NFERptEn+ FERptEn+
                RootSta: CERcvd- MultCERcvd- UERcvd- MultUERcvd-
                         FirstFatal- NonFatalMsg- FatalMsg- IntMsg 0
                ErrorSrc: ERR_COR: 0000 ERR_FATAL/NONFATAL: 0000
        Capabilities: [150 v1] Device Serial Number 00-00-00-00-00-00-00-00
        Capabilities: [300 v1] Secondary PCI Express
                LnkCtl3: LnkEquIntrruptEn- PerformEqu-
                LaneErrStat: 0
        Capabilities: [4c0 v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
                        Status: NegoPending- InProgress-
                VC1:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable- ID=1 ArbSelect=Fixed TC/VC=00
                        Status: NegoPending- InProgress-
                VC2:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable- ID=2 ArbSelect=Fixed TC/VC=00
                        Status: NegoPending- InProgress-
                VC3:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable- ID=3 ArbSelect=Fixed TC/VC=00
                        Status: NegoPending- InProgress-
        Capabilities: [900 v1] L1 PM Substates
                L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
                          PortCommonModeRestoreTime=255us PortTPowerOnTime=26us
                L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
                           T_CommonMode=255us LTR1.2_Threshold=287744ns
                L1SubCtl2: T_PwrOn=26us
        Capabilities: [a20 v1] Precision Time Measurement
                PTMCap: Requester:- Responder:+ Root:+
                PTMClockGranularity: 4ns
                PTMControl: Enabled:- RootSelected:-
                PTMEffectiveGranularity: Unknown
        Kernel driver in use: pcieport

01:00.0 Unassigned class [ff00]: Texas Instruments Device b010
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 533
        Region 0: Memory at 68220000 (32-bit, non-prefetchable) [size=64K]
        Region 1: Memory at 68234400 (32-bit, non-prefetchable) [size=512]
        Region 2: Memory at 68234000 (32-bit, non-prefetchable) [size=1K]
        Region 3: Memory at 68230000 (32-bit, non-prefetchable) [size=16K]
        Region 4: Memory at 68200000 (32-bit, non-prefetchable) [size=128K]
        Region 5: Memory at 68100000 (32-bit, non-prefetchable) [size=1M]
        Capabilities: [80] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [90] MSI: Enable+ Count=32/32 Maskable- 64bit+
                Address: 0000000001000400  Data: 0000
        Capabilities: [b0] MSI-X: Enable- Count=2048 Masked-
                Vector table: BAR=0 offset=00000080
                PBA: BAR=0 offset=00008080
        Capabilities: [c0] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 <1us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
                DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L1, Exit Latency L1 <8us
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 5GT/s (ok), Width x1 (ok)
                        TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Range B, TimeoutDis+ NROPrPrP- LTR+
                         10BitTagComp- 10BitTagReq- OBFF Via message, ExtFmt+ EETLPPrefix+, MaxEETLPPrefixes 1
                         EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
                         FRS- TPHComp- ExtTPHComp-
                         AtomicOpsCap: 32bit- 64bit- 128bitCAS-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ OBFF Disabled,
                         AtomicOpsCtl: ReqEn-
                LnkCap2: Supported Link Speeds: 2.5-5GT/s, Crosslink- Retimer- 2Retimers- DRS-
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
                         EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
                         Retimer- 2Retimers- CrosslinkRes: unsupported
        Capabilities: [100 v2] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
                HeaderLog: 00000000 00000000 00000000 00000000
        Capabilities: [150 v1] Device Serial Number 00-00-00-00-00-00-00-00
        Capabilities: [160 v1] Power Budgeting <?>
        Capabilities: [1b8 v1] Latency Tolerance Reporting
                Max snoop latency: 0ns
                Max no snoop latency: 0ns
        Capabilities: [1c0 v1] Dynamic Power Allocation <?>
        Capabilities: [300 v1] Secondary PCI Express
                LnkCtl3: LnkEquIntrruptEn- PerformEqu-
                LaneErrStat: 0
        Capabilities: [400 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [440 v1] Process Address Space ID (PASID)
                PASIDCap: Exec+ Priv+, Max PASID Width: 14
                PASIDCtl: Enable- Exec- Priv-
        Capabilities: [4c0 v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
                        Status: NegoPending- InProgress-
                VC1:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable- ID=1 ArbSelect=Fixed TC/VC=00
                        Status: NegoPending- InProgress-
                VC2:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable- ID=2 ArbSelect=Fixed TC/VC=00
                        Status: NegoPending- InProgress-
                VC3:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable- ID=3 ArbSelect=Fixed TC/VC=00
                        Status: NegoPending- InProgress-
        Capabilities: [900 v1] L1 PM Substates
                L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
                          PortCommonModeRestoreTime=255us PortTPowerOnTime=26us
                L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
                           T_CommonMode=0us LTR1.2_Threshold=287744ns
                L1SubCtl2: T_PwrOn=26us
        Capabilities: [a20 v1] Precision Time Measurement
                PTMCap: Requester:+ Responder:- Root:-
                PTMClockGranularity: Unimplemented
                PTMControl: Enabled:- RootSelected:-
                PTMEffectiveGranularity: Unknown
        Kernel driver in use: pci-endpoint-test

Regards
Bhanu Seshu Kumar Valluri 
> 
>> echo 1 > /sys/bus/pci/rescan
>> [   37.170389] pci 0000:01:00.0: [104c:b010] type 00 class 0xff0000 PCIe Endpoint
>> [   37.177781] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x0000ffff]
>> [   37.183808] pci 0000:01:00.0: BAR 1 [mem 0x00000000-0x000001ff]
>> [   37.189843] pci 0000:01:00.0: BAR 2 [mem 0x00000000-0x000003ff]
>> [   37.195802] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x00003fff]
>> [   37.201768] pci 0000:01:00.0: BAR 4 [mem 0x00000000-0x0001ffff]
>> [   37.207715] pci 0000:01:00.0: BAR 5 [mem 0x00000000-0x000fffff]
>> [   37.214040] pci 0000:01:00.0: supports D1
>> [   37.218083] pci 0000:01:00.0: PME# supported from D0 D1 D3hot
>> [   37.231890] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: assigned
>> [   37.242890] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: can't assign; no space
>> [   37.251216] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: failed to assign
>> [   37.258309] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: can't assign; no space
>> [   37.265851] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: failed to assign
>> [   37.272896] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: can't assign; no space
>> [   37.280439] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: failed to assign
>> [   37.287459] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: can't assign; no space
>> [   37.294986] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: failed to assign
>> [   37.302011] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: can't assign; no space
>> [   37.309536] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: failed to assign
>> [   37.316595] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: releasing
>> [   37.323541] pci 0000:01:00.0: BAR 5 [mem 0x68100000-0x681fffff]: assigned
>> [   37.330400] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: can't assign; no space
>> [   37.337956] pci 0000:01:00.0: BAR 4 [mem size 0x00020000]: failed to assign
>> [   37.344960] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: can't assign; no space
>> [   37.352550] pci 0000:01:00.0: BAR 0 [mem size 0x00010000]: failed to assign
>> [   37.359578] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: can't assign; no space
>> [   37.367152] pci 0000:01:00.0: BAR 3 [mem size 0x00004000]: failed to assign
>> [   37.374192] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: can't assign; no space
>> [   37.381709] pci 0000:01:00.0: BAR 2 [mem size 0x00000400]: failed to assign
>> [   37.388720] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: can't assign; no space
>> [   37.396246] pci 0000:01:00.0: BAR 1 [mem size 0x00000200]: failed to assign
>> [   37.403795] pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22
>> [   37.410513] pci-endpoint-test 0000:01:00.0: enabling device (0000 -> 0002)
>> [   37.417796] pci-endpoint-test 0000:01:00.0: Cannot perform PCI test without BAR0

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

[Ilpo Järvinen]

On Sat, 18 Oct 2025, Bhanu Seshu Kumar Valluri wrote:

> On 18/10/25 00:22, Bjorn Helgaas wrote:
> > On Fri, Oct 17, 2025 at 11:52:58PM +0530, Bhanu Seshu Kumar Valluri wrote:
> >>
> >> I want to report that this PATCH also break PCI RC port on TI-AM64-EVM.
> >>
> >> I did git bisect and it pointed to the a43ac325c7cb ("PCI: Set up bridge resources earlier")
> >>
> >> Happy to help if any testing or logs are required.
> > 
> > Thanks for the report!  Can you test this patch?
> > 
> >   https://patch.msgid.link/20251014163602.17138-1-ilpo.jarvinen@linux.intel.com
> > 
> > That patch is queued up as
> > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?id=469276c06aff
> > and should appear in v6.18-rc2 on Sunday if all goes well.
> > 
> > If that doesn't work, let us know and we'll debug this further.
> 
> I applied above patch on top of commit f406055cb18c ("Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux")
> 
> Did pci rescan and run kselftest (pci_endpoint_test). It is working.
> 
> Thanks for the patch.

Thanks for testing the revert.

> Happy to help if any testing or logs are required.

I'd be interested to understand what goes wrong with the change I was 
trying to make as I want to attempt the same change later, but with all 
known issues solved by supporting changes, obviously :-).

The log snippets you provided are unfortunately too short to contain all 
the necessary information (missing e.g. root bus resources and possibly 
other helpful details).

So if you could provide dmesg and /proc/iomem contents from broken and
working (with the revert) cases to let me easily compare them, that would 
help. Please take the dmesg with dyndbg="file drivers/pci/*.c +p" on 
kernel's cmdline.

No further actions needed beyond that until later if I need to test some 
of those supporting changes before retrying all this in the mainline. It 
may take some time, even more than one kernel cycle as there have been 
quite many regressions.


-- 
 i.

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

[Bhanu Seshu Kumar Valluri]

On 21/10/25 00:16, Ilpo Järvinen wrote:
> On Sat, 18 Oct 2025, Bhanu Seshu Kumar Valluri wrote:
> 
>> On 18/10/25 00:22, Bjorn Helgaas wrote:
>>> On Fri, Oct 17, 2025 at 11:52:58PM +0530, Bhanu Seshu Kumar Valluri wrote:
>>>>
>>>> I want to report that this PATCH also break PCI RC port on TI-AM64-EVM.
>>>>
>>>> I did git bisect and it pointed to the a43ac325c7cb ("PCI: Set up bridge resources earlier")
>>>>
>>>> Happy to help if any testing or logs are required.
>>>
>>> Thanks for the report!  Can you test this patch?
>>>
>>>   https://patch.msgid.link/20251014163602.17138-1-ilpo.jarvinen@linux.intel.com
>>>
>>> That patch is queued up as
>>> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?id=469276c06aff
>>> and should appear in v6.18-rc2 on Sunday if all goes well.
>>>
>>> If that doesn't work, let us know and we'll debug this further.
>>
>> I applied above patch on top of commit f406055cb18c ("Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux")
>>
>> Did pci rescan and run kselftest (pci_endpoint_test). It is working.
>>
>> Thanks for the patch.
> 
> Thanks for testing the revert.
> 
>> Happy to help if any testing or logs are required.
> 
> I'd be interested to understand what goes wrong with the change I was 
> trying to make as I want to attempt the same change later, but with all 
> known issues solved by supporting changes, obviously :-).
> 
> The log snippets you provided are unfortunately too short to contain all 
> the necessary information (missing e.g. root bus resources and possibly 
> other helpful details).
> 
> So if you could provide dmesg and /proc/iomem contents from broken and
> working (with the revert) cases to let me easily compare them, that would 
> help. Please take the dmesg with dyndbg="file drivers/pci/*.c +p" on 
> kernel's cmdline.
> 
> No further actions needed beyond that until later if I need to test some 
> of those supporting changes before retrying all this in the mainline. It 
> may take some time, even more than one kernel cycle as there have been 
> quite many regressions.
> 
> 
Hi

I captured logs with dyndbg="file drivers/pci/*.c +p. See the links below.

Working kernel logs
https://github.com/bhanuseshukumar/kernel_logs/blob/main/working_log

Non Working kernel logs
https://github.com/bhanuseshukumar/kernel_logs/blob/main/not_working_log

Happy to help if any testing or logs are required.

Regards,
Bhanu Seshu Kumvar Valluri

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]

On Mon, 27 Oct 2025, Bhanu Seshu Kumar Valluri wrote:
> On 21/10/25 00:16, Ilpo Järvinen wrote:
> > On Sat, 18 Oct 2025, Bhanu Seshu Kumar Valluri wrote:
> > 
> >> On 18/10/25 00:22, Bjorn Helgaas wrote:
> >>> On Fri, Oct 17, 2025 at 11:52:58PM +0530, Bhanu Seshu Kumar Valluri wrote:
> >>>>
> >>>> I want to report that this PATCH also break PCI RC port on TI-AM64-EVM.
> >>>>
> >>>> I did git bisect and it pointed to the a43ac325c7cb ("PCI: Set up bridge resources earlier")
> >>>>
> >>>> Happy to help if any testing or logs are required.
> >>>
> >>> Thanks for the report!  Can you test this patch?
> >>>
> >>>   https://patch.msgid.link/20251014163602.17138-1-ilpo.jarvinen@linux.intel.com
> >>>
> >>> That patch is queued up as
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?id=469276c06aff
> >>> and should appear in v6.18-rc2 on Sunday if all goes well.
> >>>
> >>> If that doesn't work, let us know and we'll debug this further.
> >>
> >> I applied above patch on top of commit f406055cb18c ("Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux")
> >>
> >> Did pci rescan and run kselftest (pci_endpoint_test). It is working.
> >>
> >> Thanks for the patch.
> > 
> > Thanks for testing the revert.
> > 
> >> Happy to help if any testing or logs are required.
> > 
> > I'd be interested to understand what goes wrong with the change I was 
> > trying to make as I want to attempt the same change later, but with all 
> > known issues solved by supporting changes, obviously :-).
> > 
> > The log snippets you provided are unfortunately too short to contain all 
> > the necessary information (missing e.g. root bus resources and possibly 
> > other helpful details).
> > 
> > So if you could provide dmesg and /proc/iomem contents from broken and
> > working (with the revert) cases to let me easily compare them, that would 
> > help. Please take the dmesg with dyndbg="file drivers/pci/*.c +p" on 
> > kernel's cmdline.
> > 
> > No further actions needed beyond that until later if I need to test some 
> > of those supporting changes before retrying all this in the mainline. It 
> > may take some time, even more than one kernel cycle as there have been 
> > quite many regressions.
> > 
> > 
> Hi
> 
> I captured logs with dyndbg="file drivers/pci/*.c +p. See the links below.
> 
> Working kernel logs
> https://github.com/bhanuseshukumar/kernel_logs/blob/main/working_log
> 
> Non Working kernel logs
> https://github.com/bhanuseshukumar/kernel_logs/blob/main/not_working_log
> 
> Happy to help if any testing or logs are required.

Could you try if booting with pci=realloc helps? (It might be that it is 
ineffective like I saw in some other case.)

And also test if this old size removal patch helps:

https://lore.kernel.org/linux-pci/922b1f68-a6a2-269b-880c-d594f9ca6bde@linux.intel.com/


-- 
 i.

[PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Ilpo Järvinen]

PNP resources are checked for conflicts with the other resource in the
system by quirk_system_pci_resources() that walks through all PCI
resources. quirk_system_pci_resources() correctly filters out resource
with IORESOURCE_UNSET.

Resources that do not reside within their bridge window, however, are
not properly initialized with IORESOURCE_UNSET resulting in bogus
conflicts detected in quirk_system_pci_resources():

pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
...
pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
...
pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]

Mark resources that are not contained within their bridge window with
IORESOURCE_UNSET in __pci_read_base() which resolves the false
positives for the overlap check in quirk_system_pci_resources().

Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---

This change uses resource_contains() which will reject partial overlaps.
I don't know for sure if partial overlaps should be allowed or not (but
they feel as something FW didn't set things up properly so I chose to
mark them UNSET as well).

 drivers/pci/probe.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 7f9da8c41620..097389f25853 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -205,6 +205,26 @@ static void __pci_size_rom(struct pci_dev *dev, unsigned int pos, u32 *sizes)
 	__pci_size_bars(dev, 1, pos, sizes, true);
 }
 
+static struct resource *pbus_select_window_for_res_addr(
+					const struct pci_bus *bus,
+					const struct resource *res)
+{
+	unsigned long type = res->flags & IORESOURCE_TYPE_BITS;
+	struct resource *r;
+
+	pci_bus_for_each_resource(bus, r) {
+		if (!r || r == &ioport_resource || r == &iomem_resource)
+			continue;
+
+		if ((r->flags & IORESOURCE_TYPE_BITS) != type)
+			continue;
+
+		if (resource_contains(r, res))
+			return r;
+	}
+	return NULL;
+}
+
 /**
  * __pci_read_base - Read a PCI BAR
  * @dev: the PCI device
@@ -329,6 +349,18 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
 			 res_name, (unsigned long long)region.start);
 	}
 
+	if (!(res->flags & IORESOURCE_UNSET)) {
+		struct resource *b_res;
+
+		b_res = pbus_select_window_for_res_addr(dev->bus, res);
+		if (!b_res ||
+		    b_res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED)) {
+			pci_dbg(dev, "%s %pR: no initial claim (no window)\n",
+				res_name, res);
+			res->flags |= IORESOURCE_UNSET;
+		}
+	}
+
 	goto out;
 
 
-- 
2.39.5

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Bjorn Helgaas]

On Wed, Sep 24, 2025 at 04:42:28PM +0300, Ilpo Järvinen wrote:
> PNP resources are checked for conflicts with the other resource in the
> system by quirk_system_pci_resources() that walks through all PCI
> resources. quirk_system_pci_resources() correctly filters out resource
> with IORESOURCE_UNSET.
> 
> Resources that do not reside within their bridge window, however, are
> not properly initialized with IORESOURCE_UNSET resulting in bogus
> conflicts detected in quirk_system_pci_resources():
> 
> pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> ...
> pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> ...
> pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> 
> Mark resources that are not contained within their bridge window with
> IORESOURCE_UNSET in __pci_read_base() which resolves the false
> positives for the overlap check in quirk_system_pci_resources().
> 
> Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> ---
> 
> This change uses resource_contains() which will reject partial overlaps.
> I don't know for sure if partial overlaps should be allowed or not (but
> they feel as something FW didn't set things up properly so I chose to
> mark them UNSET as well).
> 
>  drivers/pci/probe.c | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 7f9da8c41620..097389f25853 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -205,6 +205,26 @@ static void __pci_size_rom(struct pci_dev *dev, unsigned int pos, u32 *sizes)
>  	__pci_size_bars(dev, 1, pos, sizes, true);
>  }
>  
> +static struct resource *pbus_select_window_for_res_addr(
> +					const struct pci_bus *bus,
> +					const struct resource *res)
> +{
> +	unsigned long type = res->flags & IORESOURCE_TYPE_BITS;
> +	struct resource *r;
> +
> +	pci_bus_for_each_resource(bus, r) {
> +		if (!r || r == &ioport_resource || r == &iomem_resource)
> +			continue;
> +
> +		if ((r->flags & IORESOURCE_TYPE_BITS) != type)
> +			continue;
> +
> +		if (resource_contains(r, res))
> +			return r;
> +	}
> +	return NULL;
> +}
> +
>  /**
>   * __pci_read_base - Read a PCI BAR
>   * @dev: the PCI device
> @@ -329,6 +349,18 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
>  			 res_name, (unsigned long long)region.start);
>  	}
>  
> +	if (!(res->flags & IORESOURCE_UNSET)) {
> +		struct resource *b_res;
> +
> +		b_res = pbus_select_window_for_res_addr(dev->bus, res);
> +		if (!b_res ||
> +		    b_res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED)) {
> +			pci_dbg(dev, "%s %pR: no initial claim (no window)\n",
> +				res_name, res);

Should this be pci_info()?  Or is there somewhere else that we
complain about a child resource that's not contained in a bridge
window?

I recently got an internal report of child BARs being reassigned, I
think because they weren't inside a bridge window, and the dmesg log
(from an older kernel) showed the BAR reassignments, but didn't say
anything about the *reason* for the reassignment.

> +			res->flags |= IORESOURCE_UNSET;
> +		}
> +	}
> +
>  	goto out;
>  
>  
> -- 
> 2.39.5
> 

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 8414 bytes --]

On Thu, 25 Sep 2025, Bjorn Helgaas wrote:
> On Wed, Sep 24, 2025 at 04:42:28PM +0300, Ilpo Järvinen wrote:
> > PNP resources are checked for conflicts with the other resource in the
> > system by quirk_system_pci_resources() that walks through all PCI
> > resources. quirk_system_pci_resources() correctly filters out resource
> > with IORESOURCE_UNSET.
> > 
> > Resources that do not reside within their bridge window, however, are
> > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > conflicts detected in quirk_system_pci_resources():
> > 
> > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > ...
> > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > ...
> > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > 
> > Mark resources that are not contained within their bridge window with
> > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > positives for the overlap check in quirk_system_pci_resources().
> > 
> > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > ---
> > 
> > This change uses resource_contains() which will reject partial overlaps.
> > I don't know for sure if partial overlaps should be allowed or not (but
> > they feel as something FW didn't set things up properly so I chose to
> > mark them UNSET as well).
> > 
> >  drivers/pci/probe.c | 32 ++++++++++++++++++++++++++++++++
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 7f9da8c41620..097389f25853 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -205,6 +205,26 @@ static void __pci_size_rom(struct pci_dev *dev, unsigned int pos, u32 *sizes)
> >  	__pci_size_bars(dev, 1, pos, sizes, true);
> >  }
> >  
> > +static struct resource *pbus_select_window_for_res_addr(
> > +					const struct pci_bus *bus,
> > +					const struct resource *res)
> > +{
> > +	unsigned long type = res->flags & IORESOURCE_TYPE_BITS;
> > +	struct resource *r;
> > +
> > +	pci_bus_for_each_resource(bus, r) {
> > +		if (!r || r == &ioport_resource || r == &iomem_resource)

I started to wonder if those two parent "anchor" resource can ever appear 
in resources returned by pci_bus_for_each_resource()?

I've just copied those check from find_bus_resource_of_type() but it could 
be snake oil there as well.

At least I don't see them ever in my quick tests, they only appeared as 
parents of the resources this loop iterates over. But again I'm limited to 
x86 systems so not sure if my testing yields universally true answers.

> > +			continue;
> > +
> > +		if ((r->flags & IORESOURCE_TYPE_BITS) != type)
> > +			continue;
> > +
> > +		if (resource_contains(r, res))
> > +			return r;
> > +	}
> > +	return NULL;
> > +}
> > +
> >  /**
> >   * __pci_read_base - Read a PCI BAR
> >   * @dev: the PCI device
> > @@ -329,6 +349,18 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
> >  			 res_name, (unsigned long long)region.start);
> >  	}
> >  
> > +	if (!(res->flags & IORESOURCE_UNSET)) {
> > +		struct resource *b_res;
> > +
> > +		b_res = pbus_select_window_for_res_addr(dev->bus, res);
> > +		if (!b_res ||
> > +		    b_res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED)) {
> > +			pci_dbg(dev, "%s %pR: no initial claim (no window)\n",
> > +				res_name, res);
> 
> Should this be pci_info()?  Or is there somewhere else that we
> complain about a child resource that's not contained in a bridge
> window?

AFAIK, there's no other print. The kernel didn't even recognize this case 
until now so how could there have been one?!

They'd generally show up as failures later in resource assignment if the 
resource doesn't fit to the bridge window [1], which should also set 
IORESOURCE_UNSET, but good luck for inferring things from that. It's 
tedious, I know. :-) If the bridge window is large enough, the base 
address would just change where the resource fits (I think).

It can be pci_info() if you think that's better. I just picked the level 
which is the least noisy. We can go with pci_info() now and if the logging 
turns out excessive when we start to see dmesgs with it, we can of course 
adjust it later so it's not permanent either way.

In any case, there's not much user can do for these as it's the setup FW 
gave us.

> I recently got an internal report of child BARs being reassigned, I
> think because they weren't inside a bridge window, and the dmesg log
> (from an older kernel) showed the BAR reassignments, but didn't say
> anything about the *reason* for the reassignment.

Resource reassignment is only done after the resource was initially 
assigned so I'm not sure if that inferring chain is sound.

Admittedly, you didn't exactly specify how you picked up that it was 
"reassigned" so it could be just terminology that doesn't match what 
setup-bus/res.c considers as resource reassignment. That is, if BAR's 
address was simply changed from the initial, that's not "reassignment" in 
the sense used by the kernel.


I see these for ROM resource and uninitialized (0-based) resources but 
that isn't to say there couldn't be a case where the non-ROM resource was 
an invalid non-zero base address.


[footnote 1]

Some code uses IORESOURCE_UNSET where as others use ->parent to 
determine of the resource is not yet assigned. pdev_sort_resources() picks 
them based on ->parent so the resource fitting algorith tries to assign 
also resource that do not have IORESOURCE_UNSET. This entire ->parent and 
IORESOURCE_UNSET handling has lots of overlap and likely some remaining 
inconsistencies as well.

I initially thought I could entirely drop IORESOURCE_UNSET and base 
everything on ->parent but I've now changed my mind because of this 
series. We need this flag between initial reading of BARs/windows and 
running the resource fitting/assignment algorithm.

I could see some benefit from altering the meaning to something along the 
lines of IORESOURCE_INITIALLY_UNSET which is permanent flag. That 
information could then be used to determine we don't produce worse 
resource fits than what FW did. But it might be too hard to make such
change to IORESOURCE_UNSET and there are not extra bits available in 
->flags for realizing it parallel to existing flags.

It may be useful to add some warnings if UNSET and ->parent are in 
disagreement to ensure consistent state for any resource. But those 
checks would need to cope the initial transient when windows are not yet 
claimed from the resource tree which makes it harder to find good spots 
for such checks.

I generally dislike IORESOURCE_UNSET because it's semantics are not very 
clear and not properly enforced.


-- 
 i.

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Bjorn Helgaas]

On Fri, Sep 26, 2025 at 03:21:17PM +0300, Ilpo Järvinen wrote:
> On Thu, 25 Sep 2025, Bjorn Helgaas wrote:
> > On Wed, Sep 24, 2025 at 04:42:28PM +0300, Ilpo Järvinen wrote:
> > > PNP resources are checked for conflicts with the other resource in the
> > > system by quirk_system_pci_resources() that walks through all PCI
> > > resources. quirk_system_pci_resources() correctly filters out resource
> > > with IORESOURCE_UNSET.
> > > 
> > > Resources that do not reside within their bridge window, however, are
> > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > conflicts detected in quirk_system_pci_resources():

> > > @@ -329,6 +349,18 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
> > >  			 res_name, (unsigned long long)region.start);
> > >  	}
> > >  
> > > +	if (!(res->flags & IORESOURCE_UNSET)) {
> > > +		struct resource *b_res;
> > > +
> > > +		b_res = pbus_select_window_for_res_addr(dev->bus, res);
> > > +		if (!b_res ||
> > > +		    b_res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED)) {
> > > +			pci_dbg(dev, "%s %pR: no initial claim (no window)\n",
> > > +				res_name, res);
> > 
> > Should this be pci_info()?  Or is there somewhere else that we
> > complain about a child resource that's not contained in a bridge
> > window?
> 
> AFAIK, there's no other print. The kernel didn't even recognize this case 
> until now so how could there have been one?!

> They'd generally show up as failures later in resource assignment if the 
> resource doesn't fit to the bridge window [1], which should also set 
> IORESOURCE_UNSET, but good luck for inferring things from that. It's 
> tedious, I know. :-) If the bridge window is large enough, the base 
> address would just change where the resource fits (I think).
> 
> It can be pci_info() if you think that's better. I just picked the level 
> which is the least noisy. We can go with pci_info() now and if the logging 
> turns out excessive when we start to see dmesgs with it, we can of course 
> adjust it later so it's not permanent either way.
> 
> In any case, there's not much user can do for these as it's the setup FW 
> gave us.
> 
> > I recently got an internal report of child BARs being reassigned, I
> > think because they weren't inside a bridge window, and the dmesg log
> > (from an older kernel) showed the BAR reassignments, but didn't say
> > anything about the *reason* for the reassignment.
> 
> Resource reassignment is only done after the resource was initially 
> assigned so I'm not sure if that inferring chain is sound.
> 
> Admittedly, you didn't exactly specify how you picked up that it was 
> "reassigned" so it could be just terminology that doesn't match what 
> setup-bus/res.c considers as resource reassignment. That is, if BAR's 
> address was simply changed from the initial, that's not "reassignment" in 
> the sense used by the kernel.

Here's the case I saw (a v6.1 kernel, so old log messages):

  pci 0000:00:00.0: bridge window [mem 0x80000000-0x97fffffff 64bit pref] to [bus 01-05] add_size 80000000 add_align 80000000
  pci 0000:00:00.0: BAR 15: assigned [mem 0x380000000-0xcffffffff 64bit pref]
  pci 0000:01:01.0: BAR 0: [mem 0xb00000000-0xbffffffff 64bit pref]
  ...
  pci 0000:01:01.7: BAR 0: [mem 0x400000000-0x4ffffffff 64bit pref]
  pci 0000:01:01.0: BAR 0: assigned [mem 0x400000000-0x4ffffffff 64bit pref]

Obviously these initial BAR 0 values don't fit in the
[0x80000000-0x97fffffff] bridge window, so I think we moved and
expanded it and then assigned the BARs to be inside.

I was thinking might get the "can't claim; no compatible bridge
window" message in pci_claim_resource() as a clue, but we didn't.

This *seems* like a firmware defect: why would firmware bother to
program these BARs at all unless it also made a bridge window that
could reach them.

Bjorn

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 4323 bytes --]

On Fri, 26 Sep 2025, Bjorn Helgaas wrote:
> On Fri, Sep 26, 2025 at 03:21:17PM +0300, Ilpo Järvinen wrote:
> > On Thu, 25 Sep 2025, Bjorn Helgaas wrote:
> > > On Wed, Sep 24, 2025 at 04:42:28PM +0300, Ilpo Järvinen wrote:
> > > > PNP resources are checked for conflicts with the other resource in the
> > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > with IORESOURCE_UNSET.
> > > > 
> > > > Resources that do not reside within their bridge window, however, are
> > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > conflicts detected in quirk_system_pci_resources():
> 
> > > > @@ -329,6 +349,18 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
> > > >  			 res_name, (unsigned long long)region.start);
> > > >  	}
> > > >  
> > > > +	if (!(res->flags & IORESOURCE_UNSET)) {
> > > > +		struct resource *b_res;
> > > > +
> > > > +		b_res = pbus_select_window_for_res_addr(dev->bus, res);
> > > > +		if (!b_res ||
> > > > +		    b_res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED)) {
> > > > +			pci_dbg(dev, "%s %pR: no initial claim (no window)\n",
> > > > +				res_name, res);
> > > 
> > > Should this be pci_info()?  Or is there somewhere else that we
> > > complain about a child resource that's not contained in a bridge
> > > window?
> > 
> > AFAIK, there's no other print. The kernel didn't even recognize this case 
> > until now so how could there have been one?!
> 
> > They'd generally show up as failures later in resource assignment if the 
> > resource doesn't fit to the bridge window [1], which should also set 
> > IORESOURCE_UNSET, but good luck for inferring things from that. It's 
> > tedious, I know. :-) If the bridge window is large enough, the base 
> > address would just change where the resource fits (I think).
> > 
> > It can be pci_info() if you think that's better. I just picked the level 
> > which is the least noisy. We can go with pci_info() now and if the logging 
> > turns out excessive when we start to see dmesgs with it, we can of course 
> > adjust it later so it's not permanent either way.
> > 
> > In any case, there's not much user can do for these as it's the setup FW 
> > gave us.
> > 
> > > I recently got an internal report of child BARs being reassigned, I
> > > think because they weren't inside a bridge window, and the dmesg log
> > > (from an older kernel) showed the BAR reassignments, but didn't say
> > > anything about the *reason* for the reassignment.
> > 
> > Resource reassignment is only done after the resource was initially 
> > assigned so I'm not sure if that inferring chain is sound.
> > 
> > Admittedly, you didn't exactly specify how you picked up that it was 
> > "reassigned" so it could be just terminology that doesn't match what 
> > setup-bus/res.c considers as resource reassignment. That is, if BAR's 
> > address was simply changed from the initial, that's not "reassignment" in 
> > the sense used by the kernel.
> 
> Here's the case I saw (a v6.1 kernel, so old log messages):
> 
>   pci 0000:00:00.0: bridge window [mem 0x80000000-0x97fffffff 64bit pref] to [bus 01-05] add_size 80000000 add_align 80000000
>   pci 0000:00:00.0: BAR 15: assigned [mem 0x380000000-0xcffffffff 64bit pref]
>   pci 0000:01:01.0: BAR 0: [mem 0xb00000000-0xbffffffff 64bit pref]
>   ...
>   pci 0000:01:01.7: BAR 0: [mem 0x400000000-0x4ffffffff 64bit pref]
>   pci 0000:01:01.0: BAR 0: assigned [mem 0x400000000-0x4ffffffff 64bit pref]
> 
> Obviously these initial BAR 0 values don't fit in the
> [0x80000000-0x97fffffff] bridge window, so I think we moved and
> expanded it and then assigned the BARs to be inside.
> 
> I was thinking might get the "can't claim; no compatible bridge
> window" message in pci_claim_resource() as a clue, but we didn't.

Is pci_bus_claim_resources() called in this case? That requires 
preserve_config. In my tests pci_bus_allocate_dev_resources() is never 
called, only bridge window resources are claimed.

> This *seems* like a firmware defect: why would firmware bother to
> program these BARs at all unless it also made a bridge window that
> could reach them.

-- 
 i.

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Geert Uytterhoeven]

Hi Ilpo,

On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> PNP resources are checked for conflicts with the other resource in the
> system by quirk_system_pci_resources() that walks through all PCI
> resources. quirk_system_pci_resources() correctly filters out resource
> with IORESOURCE_UNSET.
>
> Resources that do not reside within their bridge window, however, are
> not properly initialized with IORESOURCE_UNSET resulting in bogus
> conflicts detected in quirk_system_pci_resources():
>
> pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> ...
> pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> ...
> pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
>
> Mark resources that are not contained within their bridge window with
> IORESOURCE_UNSET in __pci_read_base() which resolves the false
> positives for the overlap check in quirk_system_pci_resources().
>
> Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
Mark resources IORESOURCE_UNSET when outside bridge windows") in
linux-next/master next-20250929 pci/next

This replaces the actual resources by their sizes in the boot log on
e.g. on R-Car M2-W:

     pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
     pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff
-> 0x00ee080000
     pci-rcar-gen2 ee090000.pci: PCI: revision 11
     pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
     pci_bus 0000:00: root bus resource [bus 00]
     pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
     pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
PCI endpoint
    -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
    -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
    +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
    +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
     pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
PCI endpoint
    -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
    +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
     pci 0000:00:01.0: supports D1 D2
     pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
     pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
PCI endpoint
    -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
    +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
     pci 0000:00:02.0: supports D1 D2
     pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
     PCI: bus0: Fast back to back transfers disabled
     pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
     pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
     pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]

Is that intentional?

> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -205,6 +205,26 @@ static void __pci_size_rom(struct pci_dev *dev, unsigned int pos, u32 *sizes)
>         __pci_size_bars(dev, 1, pos, sizes, true);
>  }
>
> +static struct resource *pbus_select_window_for_res_addr(
> +                                       const struct pci_bus *bus,
> +                                       const struct resource *res)
> +{
> +       unsigned long type = res->flags & IORESOURCE_TYPE_BITS;
> +       struct resource *r;
> +
> +       pci_bus_for_each_resource(bus, r) {
> +               if (!r || r == &ioport_resource || r == &iomem_resource)
> +                       continue;
> +
> +               if ((r->flags & IORESOURCE_TYPE_BITS) != type)
> +                       continue;
> +
> +               if (resource_contains(r, res))
> +                       return r;
> +       }
> +       return NULL;
> +}
> +
>  /**
>   * __pci_read_base - Read a PCI BAR
>   * @dev: the PCI device
> @@ -329,6 +349,18 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
>                          res_name, (unsigned long long)region.start);
>         }
>
> +       if (!(res->flags & IORESOURCE_UNSET)) {
> +               struct resource *b_res;
> +
> +               b_res = pbus_select_window_for_res_addr(dev->bus, res);
> +               if (!b_res ||
> +                   b_res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED)) {
> +                       pci_dbg(dev, "%s %pR: no initial claim (no window)\n",
> +                               res_name, res);
> +                       res->flags |= IORESOURCE_UNSET;
> +               }
> +       }
> +
>         goto out;
>
>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 7799 bytes --]

On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > PNP resources are checked for conflicts with the other resource in the
> > system by quirk_system_pci_resources() that walks through all PCI
> > resources. quirk_system_pci_resources() correctly filters out resource
> > with IORESOURCE_UNSET.
> >
> > Resources that do not reside within their bridge window, however, are
> > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > conflicts detected in quirk_system_pci_resources():
> >
> > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > ...
> > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > ...
> > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> >
> > Mark resources that are not contained within their bridge window with
> > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > positives for the overlap check in quirk_system_pci_resources().
> >
> > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> 
> Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> Mark resources IORESOURCE_UNSET when outside bridge windows") in
> linux-next/master next-20250929 pci/next

Hi Geert,

I really appreciate you paying attention!!

> This replaces the actual resources by their sizes in the boot log on
> e.g. on R-Car M2-W:
> 
>      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
>      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff
> -> 0x00ee080000
>      pci-rcar-gen2 ee090000.pci: PCI: revision 11
>      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
>      pci_bus 0000:00: root bus resource [bus 00]
>      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
>      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
> PCI endpoint
>     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
>     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]

What is going to be the parent of these resources? They don't seem to fall
under the root bus resource above in which case the output change is 
intentional so they don't appear as if address range would be "okay".

When IORESOURCE_UNSET is set in a resource, %pR does not print the start 
and end addresses.

>     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
>     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
>      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> PCI endpoint
>     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
>     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]

For this resource, it's very much intentional. It's a zero-based BAR which 
was left without IORESOURCE_UNSET prior to my patch leading to others part 
of the kernel to think that resource range valid and in use (in your 
case it's so small it wouldn't collide with anything but it wasn't 
properly set up resource, nonetheless).

>      pci 0000:00:01.0: supports D1 D2
>      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
>      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
> PCI endpoint
>     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
>     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]

And this as well is very much intentional.

>      pci 0000:00:02.0: supports D1 D2
>      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
>      PCI: bus0: Fast back to back transfers disabled
>      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
>      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
>      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> 
> Is that intentional?

There's also that pci_dbg() in the patch which would show the original 
addresses (print the resource before setting IORESOURCE_UNSET) but to see 
it one would need to enable it with dyndbg=... Bjorn was thinking of 
making that pci_info() though so it would appear always.

Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs 
getting assigned anywhere.

You didn't report any issues beyond textual changes in the log, I suppose 
there were none beyond the log differences?

-- 
 i.

> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -205,6 +205,26 @@ static void __pci_size_rom(struct pci_dev *dev, unsigned int pos, u32 *sizes)
> >         __pci_size_bars(dev, 1, pos, sizes, true);
> >  }
> >
> > +static struct resource *pbus_select_window_for_res_addr(
> > +                                       const struct pci_bus *bus,
> > +                                       const struct resource *res)
> > +{
> > +       unsigned long type = res->flags & IORESOURCE_TYPE_BITS;
> > +       struct resource *r;
> > +
> > +       pci_bus_for_each_resource(bus, r) {
> > +               if (!r || r == &ioport_resource || r == &iomem_resource)
> > +                       continue;
> > +
> > +               if ((r->flags & IORESOURCE_TYPE_BITS) != type)
> > +                       continue;
> > +
> > +               if (resource_contains(r, res))
> > +                       return r;
> > +       }
> > +       return NULL;
> > +}
> > +
> >  /**
> >   * __pci_read_base - Read a PCI BAR
> >   * @dev: the PCI device
> > @@ -329,6 +349,18 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
> >                          res_name, (unsigned long long)region.start);
> >         }
> >
> > +       if (!(res->flags & IORESOURCE_UNSET)) {
> > +               struct resource *b_res;
> > +
> > +               b_res = pbus_select_window_for_res_addr(dev->bus, res);
> > +               if (!b_res ||
> > +                   b_res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED)) {
> > +                       pci_dbg(dev, "%s %pR: no initial claim (no window)\n",
> > +                               res_name, res);
> > +                       res->flags |= IORESOURCE_UNSET;
> > +               }
> > +       }
> > +
> >         goto out;
> >
> >
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> 

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Geert Uytterhoeven]

Hi Ilpo,

On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > PNP resources are checked for conflicts with the other resource in the
> > > system by quirk_system_pci_resources() that walks through all PCI
> > > resources. quirk_system_pci_resources() correctly filters out resource
> > > with IORESOURCE_UNSET.
> > >
> > > Resources that do not reside within their bridge window, however, are
> > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > conflicts detected in quirk_system_pci_resources():
> > >
> > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > ...
> > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > ...
> > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > >
> > > Mark resources that are not contained within their bridge window with
> > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > positives for the overlap check in quirk_system_pci_resources().
> > >
> > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> >
> > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > linux-next/master next-20250929 pci/next

> > This replaces the actual resources by their sizes in the boot log on
> > e.g. on R-Car M2-W:
> >
> >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> >      pci_bus 0000:00: root bus resource [bus 00]
> >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
>
> What is going to be the parent of these resources? They don't seem to fall
> under the root bus resource above in which case the output change is
> intentional so they don't appear as if address range would be "okay".

From /proc/iomem:

    ee080000-ee08ffff : pci@ee090000
      ee080000-ee080fff : 0000:00:01.0
        ee080000-ee080fff : ohci_hcd
      ee081000-ee0810ff : 0000:00:02.0
        ee081000-ee0810ff : ehci_hcd
    ee090000-ee090bff : ee090000.pci pci@ee090000
    ee0c0000-ee0cffff : pci@ee0d0000
      ee0c0000-ee0c0fff : 0001:01:01.0
        ee0c0000-ee0c0fff : ohci_hcd
      ee0c1000-ee0c10ff : 0001:01:02.0
        ee0c1000-ee0c10ff : ehci_hcd

> When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> and end addresses.

Yeah, that's how I found this commit, without bisecting ;-)

> >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
>
> For this resource, it's very much intentional. It's a zero-based BAR which
> was left without IORESOURCE_UNSET prior to my patch leading to others part
> of the kernel to think that resource range valid and in use (in your
> case it's so small it wouldn't collide with anything but it wasn't
> properly set up resource, nonetheless).
>
> >      pci 0000:00:01.0: supports D1 D2
> >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
>
> And this as well is very much intentional.
>
> >      pci 0000:00:02.0: supports D1 D2
> >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> >      PCI: bus0: Fast back to back transfers disabled
> >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> >
> > Is that intentional?
>
> There's also that pci_dbg() in the patch which would show the original
> addresses (print the resource before setting IORESOURCE_UNSET) but to see
> it one would need to enable it with dyndbg=... Bjorn was thinking of
> making that pci_info() though so it would appear always.
>
> Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> getting assigned anywhere.

The above log is almost complete (lacked enabling the device afterwards).

AFAIU, the BARs come from the reg and ranges properties in the
PCI controller nodes;
https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562

The full related log for this device, for both instances, with the pci_dbg()
changes to pci_info():

     pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
     pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff
-> 0x00ee080000
     pci-rcar-gen2 ee090000.pci: PCI: revision 11
     pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
     pci_bus 0000:00: root bus resource [bus 00]
     pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
     pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
PCI endpoint
    -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
    -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
    +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
claim (no window)
    +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
    +pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
initial claim (no window)
    +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
     pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
PCI endpoint
    -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
    +pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
claim (no window)
    +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
     pci 0000:00:01.0: supports D1 D2
     pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
     pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
PCI endpoint
    -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
    +pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
claim (no window)
    +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
     pci 0000:00:02.0: supports D1 D2
     pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
     PCI: bus0: Fast back to back transfers disabled
     pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
     pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
     pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
     pci 0000:00:01.0: enabling device (0140 -> 0142)
     pci 0000:00:02.0: enabling device (0140 -> 0142)
     pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
     pci-rcar-gen2 ee0d0000.pci:      MEM 0x00ee0c0000..0x00ee0cffff
-> 0x00ee0c0000
     pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
     pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
     pci_bus 0001:01: root bus resource [bus 01]
     pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
     pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional
PCI endpoint
    -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
    -pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
    +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial
claim (no window)
    +pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
    +pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
initial claim (no window)
    +pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
     pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional
PCI endpoint
    -pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]
    +pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
claim (no window)
    +pci 0001:01:01.0: BAR 0 [mem size 0x00001000]
     pci 0001:01:01.0: supports D1 D2
     pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
     pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
PCI endpoint
    -pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]
    +pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
claim (no window)
    +pci 0001:01:02.0: BAR 0 [mem size 0x00000100]
     pci 0001:01:02.0: supports D1 D2
     pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
     PCI: bus1: Fast back to back transfers disabled
     pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
     pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
     pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
     pci 0001:01:01.0: enabling device (0140 -> 0142)
     pci 0001:01:02.0: enabling device (0140 -> 0142)

> You didn't report any issues beyond textual changes in the log, I suppose
> there were none beyond the log differences?

Sorry, I should have done a little bit more testing.  This is the funny
on-chip Renesas R-Car Gen2 PCI host controller with integrated OHCI/EHCI
PCI devices.  I don't have any USB devices connected, but "lspci -v"
output is the same before/after, and the OHCI/EHCI drivers probe fine.

BTW, I am seeing similar changes on rts7751r2d (qemu SuperH target r2d):

     PCI host bridge to bus 0000:00
     pci_bus 0000:00: root bus resource [io  0x1000-0x3fffff]
     pci_bus 0000:00: root bus resource [mem 0xfd000000-0xfdffffff]
     pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
     pci 0000:00:00.0: [1054:350e] type 00 class 0x060000 conventional
PCI endpoint
     pci 0000:00:00.0: [Firmware Bug]: BAR 0: invalid; can't size
     pci 0000:00:00.0: [Firmware Bug]: BAR 1: invalid; can't size
     pci 0000:00:00.0: [Firmware Bug]: BAR 2: invalid; can't size
     pci 0000:00:02.0: [10ec:8139] type 00 class 0x020000 conventional
PCI endpoint
    -pci 0000:00:02.0: BAR 0 [io  0x0000-0x00ff]
    -pci 0000:00:02.0: BAR 1 [mem 0x00000000-0x000000ff]
    -pci 0000:00:02.0: ROM [mem 0x00000000-0x0007ffff pref]
    +pci 0000:00:02.0: BAR 0 [io  0x0000-0x00ff]: no initial claim (no window)
    +pci 0000:00:02.0: BAR 0 [io  size 0x0100]
    +pci 0000:00:02.0: BAR 1 [mem 0x00000000-0x000000ff]: no initial
claim (no window)
    +pci 0000:00:02.0: BAR 1 [mem size 0x00000100]
    +pci 0000:00:02.0: ROM [mem 0x00000000-0x0007ffff pref]: no
initial claim (no window)
    +pci 0000:00:02.0: ROM [mem size 0x00080000 pref]
     pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
     pci 0000:00:02.0: ROM [mem 0xfd000000-0xfd07ffff pref]: assigned
     pci 0000:00:02.0: BAR 0 [io  0x1000-0x10ff]: assigned
     pci 0000:00:02.0: BAR 1 [mem 0xfd080000-0xfd0800ff]: assigned

All of these look legitimate to me, as they all start at zero.

Thanks!


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 14676 bytes --]

On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > PNP resources are checked for conflicts with the other resource in the
> > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > with IORESOURCE_UNSET.
> > > >
> > > > Resources that do not reside within their bridge window, however, are
> > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > conflicts detected in quirk_system_pci_resources():
> > > >
> > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > ...
> > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > ...
> > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > >
> > > > Mark resources that are not contained within their bridge window with
> > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > positives for the overlap check in quirk_system_pci_resources().
> > > >
> > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > >
> > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > linux-next/master next-20250929 pci/next
> 
> > > This replaces the actual resources by their sizes in the boot log on
> > > e.g. on R-Car M2-W:
> > >
> > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > >      pci_bus 0000:00: root bus resource [bus 00]
> > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> >
> > What is going to be the parent of these resources? They don't seem to fall
> > under the root bus resource above in which case the output change is
> > intentional so they don't appear as if address range would be "okay".
> 
> >From /proc/iomem:
> 
>     ee080000-ee08ffff : pci@ee090000
>       ee080000-ee080fff : 0000:00:01.0
>         ee080000-ee080fff : ohci_hcd
>       ee081000-ee0810ff : 0000:00:02.0
>         ee081000-ee0810ff : ehci_hcd
>     ee090000-ee090bff : ee090000.pci pci@ee090000

Okay, so this seem to appear in the resource tree but not among the root 
bus resources.

>     ee0c0000-ee0cffff : pci@ee0d0000
>       ee0c0000-ee0c0fff : 0001:01:01.0
>         ee0c0000-ee0c0fff : ohci_hcd
>       ee0c1000-ee0c10ff : 0001:01:02.0
>         ee0c1000-ee0c10ff : ehci_hcd
> 
> > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > and end addresses.
> 
> Yeah, that's how I found this commit, without bisecting ;-)
> 
> > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> >
> > For this resource, it's very much intentional. It's a zero-based BAR which
> > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > of the kernel to think that resource range valid and in use (in your
> > case it's so small it wouldn't collide with anything but it wasn't
> > properly set up resource, nonetheless).
> >
> > >      pci 0000:00:01.0: supports D1 D2
> > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> >
> > And this as well is very much intentional.
> >
> > >      pci 0000:00:02.0: supports D1 D2
> > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > >      PCI: bus0: Fast back to back transfers disabled
> > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > >
> > > Is that intentional?
> >
> > There's also that pci_dbg() in the patch which would show the original
> > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > making that pci_info() though so it would appear always.
> >
> > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > getting assigned anywhere.
> 
> The above log is almost complete (lacked enabling the device afterwards).
> 
> AFAIU, the BARs come from the reg and ranges properties in the
> PCI controller nodes;
> https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562

Thanks, although I had already found this line by grep. I was just 
expecting the address appear among root bus resources too.

Curiously enough, pci_register_host_bridge() seems to try to add some 
resource from that list into bus and it's what prints those "root bus 
resource" lines and ee090000 is not among the printed lines despite 
appearing in /proc/iomem. As is, the resource tree and PCI bus view on the 
resources seems to be in disagreement and I'm not sure what to make of it.

But before considering going into that direction or figuring out why this 
ee090000 resource does not appear among root bus resources, could you 
check if the attached patch changes behavior for the resource which are 
non-zero based?

-- 
 i.

> The full related log for this device, for both instances, with the pci_dbg()
> changes to pci_info():
> 
>      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
>      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff
> -> 0x00ee080000
>      pci-rcar-gen2 ee090000.pci: PCI: revision 11
>      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
>      pci_bus 0000:00: root bus resource [bus 00]
>      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
>      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
> PCI endpoint
>     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
>     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
>     +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
> claim (no window)
>     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
>     +pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> initial claim (no window)
>     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
>      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> PCI endpoint
>     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
>     +pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
> claim (no window)
>     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
>      pci 0000:00:01.0: supports D1 D2
>      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
>      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
> PCI endpoint
>     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
>     +pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
> claim (no window)
>     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
>      pci 0000:00:02.0: supports D1 D2
>      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
>      PCI: bus0: Fast back to back transfers disabled
>      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
>      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
>      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
>      pci 0000:00:01.0: enabling device (0140 -> 0142)
>      pci 0000:00:02.0: enabling device (0140 -> 0142)
>      pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
>      pci-rcar-gen2 ee0d0000.pci:      MEM 0x00ee0c0000..0x00ee0cffff
> -> 0x00ee0c0000
>      pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
>      pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
>      pci_bus 0001:01: root bus resource [bus 01]
>      pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
>      pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional
> PCI endpoint
>     -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
>     -pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
>     +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial
> claim (no window)
>     +pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
>     +pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> initial claim (no window)
>     +pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
>      pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> PCI endpoint
>     -pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]
>     +pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
> claim (no window)
>     +pci 0001:01:01.0: BAR 0 [mem size 0x00001000]
>      pci 0001:01:01.0: supports D1 D2
>      pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
>      pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
> PCI endpoint
>     -pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]
>     +pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
> claim (no window)
>     +pci 0001:01:02.0: BAR 0 [mem size 0x00000100]
>      pci 0001:01:02.0: supports D1 D2
>      pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
>      PCI: bus1: Fast back to back transfers disabled
>      pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
>      pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
>      pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
>      pci 0001:01:01.0: enabling device (0140 -> 0142)
>      pci 0001:01:02.0: enabling device (0140 -> 0142)
> 
> > You didn't report any issues beyond textual changes in the log, I suppose
> > there were none beyond the log differences?
> 
> Sorry, I should have done a little bit more testing.  This is the funny
> on-chip Renesas R-Car Gen2 PCI host controller with integrated OHCI/EHCI
> PCI devices.  I don't have any USB devices connected, but "lspci -v"
> output is the same before/after, and the OHCI/EHCI drivers probe fine.
> 
> BTW, I am seeing similar changes on rts7751r2d (qemu SuperH target r2d):
> 
>      PCI host bridge to bus 0000:00
>      pci_bus 0000:00: root bus resource [io  0x1000-0x3fffff]
>      pci_bus 0000:00: root bus resource [mem 0xfd000000-0xfdffffff]
>      pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
>      pci 0000:00:00.0: [1054:350e] type 00 class 0x060000 conventional
> PCI endpoint
>      pci 0000:00:00.0: [Firmware Bug]: BAR 0: invalid; can't size
>      pci 0000:00:00.0: [Firmware Bug]: BAR 1: invalid; can't size
>      pci 0000:00:00.0: [Firmware Bug]: BAR 2: invalid; can't size
>      pci 0000:00:02.0: [10ec:8139] type 00 class 0x020000 conventional
> PCI endpoint
>     -pci 0000:00:02.0: BAR 0 [io  0x0000-0x00ff]
>     -pci 0000:00:02.0: BAR 1 [mem 0x00000000-0x000000ff]
>     -pci 0000:00:02.0: ROM [mem 0x00000000-0x0007ffff pref]
>     +pci 0000:00:02.0: BAR 0 [io  0x0000-0x00ff]: no initial claim (no window)
>     +pci 0000:00:02.0: BAR 0 [io  size 0x0100]
>     +pci 0000:00:02.0: BAR 1 [mem 0x00000000-0x000000ff]: no initial
> claim (no window)
>     +pci 0000:00:02.0: BAR 1 [mem size 0x00000100]
>     +pci 0000:00:02.0: ROM [mem 0x00000000-0x0007ffff pref]: no
> initial claim (no window)
>     +pci 0000:00:02.0: ROM [mem size 0x00080000 pref]
>      pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
>      pci 0000:00:02.0: ROM [mem 0xfd000000-0xfd07ffff pref]: assigned
>      pci 0000:00:02.0: BAR 0 [io  0x1000-0x10ff]: assigned
>      pci 0000:00:02.0: BAR 1 [mem 0xfd080000-0xfd0800ff]: assigned
> 
> All of these look legitimate to me, as they all start at zero.
> 
> Thanks!
> 
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=host_bridge_res.patch, Size: 1626 bytes --]

From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Subject: [PATCH] PCI: Check also host bridge windows in pbus_select_window_for_res_addr()

Check also host bridge windows in pbus_select_window_for_res_addr() as
they don't seem to appear in appear as root bus resources.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

---
 drivers/pci/probe.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 097389f25853..66f0763113cb 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -206,10 +206,12 @@ static void __pci_size_rom(struct pci_dev *dev, unsigned int pos, u32 *sizes)
 }
 
 static struct resource *pbus_select_window_for_res_addr(
-					const struct pci_bus *bus,
+					struct pci_bus *bus,
 					const struct resource *res)
 {
 	unsigned long type = res->flags & IORESOURCE_TYPE_BITS;
+	struct pci_host_bridge *host_bridge;
+	struct resource_entry *window;
 	struct resource *r;
 
 	pci_bus_for_each_resource(bus, r) {
@@ -222,6 +224,19 @@ static struct resource *pbus_select_window_for_res_addr(
 		if (resource_contains(r, res))
 			return r;
 	}
+
+	if (!pci_is_root_bus(bus))
+		return NULL;
+
+	host_bridge = pci_find_host_bridge(bus);
+	resource_list_for_each_entry(window, &host_bridge->windows) {
+		if ((window->res->flags & IORESOURCE_TYPE_BITS) != type)
+			continue;
+
+		if (resource_contains(window->res, res))
+			return r;
+	}
+
 	return NULL;
 }
 

-- 
tg: (7970e5d038d5..) fix/check-host-bridge-windows (depends on: fix/iov-resource-init)

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Geert Uytterhoeven]

Hi Ilpo,

On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > with IORESOURCE_UNSET.
> > > > >
> > > > > Resources that do not reside within their bridge window, however, are
> > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > conflicts detected in quirk_system_pci_resources():
> > > > >
> > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > ...
> > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > ...
> > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > >
> > > > > Mark resources that are not contained within their bridge window with
> > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > >
> > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > >
> > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > linux-next/master next-20250929 pci/next
> >
> > > > This replaces the actual resources by their sizes in the boot log on
> > > > e.g. on R-Car M2-W:
> > > >
> > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > >
> > > What is going to be the parent of these resources? They don't seem to fall
> > > under the root bus resource above in which case the output change is
> > > intentional so they don't appear as if address range would be "okay".
> >
> > >From /proc/iomem:
> >
> >     ee080000-ee08ffff : pci@ee090000
> >       ee080000-ee080fff : 0000:00:01.0
> >         ee080000-ee080fff : ohci_hcd
> >       ee081000-ee0810ff : 0000:00:02.0
> >         ee081000-ee0810ff : ehci_hcd
> >     ee090000-ee090bff : ee090000.pci pci@ee090000
>
> Okay, so this seem to appear in the resource tree but not among the root
> bus resources.
>
> >     ee0c0000-ee0cffff : pci@ee0d0000
> >       ee0c0000-ee0c0fff : 0001:01:01.0
> >         ee0c0000-ee0c0fff : ohci_hcd
> >       ee0c1000-ee0c10ff : 0001:01:02.0
> >         ee0c1000-ee0c10ff : ehci_hcd
> >
> > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > and end addresses.
> >
> > Yeah, that's how I found this commit, without bisecting ;-)
> >
> > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > >
> > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > of the kernel to think that resource range valid and in use (in your
> > > case it's so small it wouldn't collide with anything but it wasn't
> > > properly set up resource, nonetheless).
> > >
> > > >      pci 0000:00:01.0: supports D1 D2
> > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > >
> > > And this as well is very much intentional.
> > >
> > > >      pci 0000:00:02.0: supports D1 D2
> > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > >      PCI: bus0: Fast back to back transfers disabled
> > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > >
> > > > Is that intentional?
> > >
> > > There's also that pci_dbg() in the patch which would show the original
> > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > making that pci_info() though so it would appear always.
> > >
> > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > getting assigned anywhere.
> >
> > The above log is almost complete (lacked enabling the device afterwards).
> >
> > AFAIU, the BARs come from the reg and ranges properties in the
> > PCI controller nodes;
> > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
>
> Thanks, although I had already found this line by grep. I was just
> expecting the address appear among root bus resources too.
>
> Curiously enough, pci_register_host_bridge() seems to try to add some
> resource from that list into bus and it's what prints those "root bus
> resource" lines and ee090000 is not among the printed lines despite
> appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> resources seems to be in disagreement and I'm not sure what to make of it.
>
> But before considering going into that direction or figuring out why this
> ee090000 resource does not appear among root bus resources, could you
> check if the attached patch changes behavior for the resource which are
> non-zero based?

This patch has no impact on dmesg, lspci output, or /proc/iomem
for pci-rcar-gen2.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 9134 bytes --]

On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > > with IORESOURCE_UNSET.
> > > > > >
> > > > > > Resources that do not reside within their bridge window, however, are
> > > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > > conflicts detected in quirk_system_pci_resources():
> > > > > >
> > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > > ...
> > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > > ...
> > > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > >
> > > > > > Mark resources that are not contained within their bridge window with
> > > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > > >
> > > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > >
> > > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > > linux-next/master next-20250929 pci/next
> > >
> > > > > This replaces the actual resources by their sizes in the boot log on
> > > > > e.g. on R-Car M2-W:
> > > > >
> > > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > > >
> > > > What is going to be the parent of these resources? They don't seem to fall
> > > > under the root bus resource above in which case the output change is
> > > > intentional so they don't appear as if address range would be "okay".
> > >
> > > >From /proc/iomem:
> > >
> > >     ee080000-ee08ffff : pci@ee090000
> > >       ee080000-ee080fff : 0000:00:01.0
> > >         ee080000-ee080fff : ohci_hcd
> > >       ee081000-ee0810ff : 0000:00:02.0
> > >         ee081000-ee0810ff : ehci_hcd
> > >     ee090000-ee090bff : ee090000.pci pci@ee090000
> >
> > Okay, so this seem to appear in the resource tree but not among the root
> > bus resources.
> >
> > >     ee0c0000-ee0cffff : pci@ee0d0000
> > >       ee0c0000-ee0c0fff : 0001:01:01.0
> > >         ee0c0000-ee0c0fff : ohci_hcd
> > >       ee0c1000-ee0c10ff : 0001:01:02.0
> > >         ee0c1000-ee0c10ff : ehci_hcd
> > >
> > > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > > and end addresses.
> > >
> > > Yeah, that's how I found this commit, without bisecting ;-)
> > >
> > > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > >
> > > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > > of the kernel to think that resource range valid and in use (in your
> > > > case it's so small it wouldn't collide with anything but it wasn't
> > > > properly set up resource, nonetheless).
> > > >
> > > > >      pci 0000:00:01.0: supports D1 D2
> > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > >
> > > > And this as well is very much intentional.
> > > >
> > > > >      pci 0000:00:02.0: supports D1 D2
> > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > >
> > > > > Is that intentional?
> > > >
> > > > There's also that pci_dbg() in the patch which would show the original
> > > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > > making that pci_info() though so it would appear always.
> > > >
> > > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > > getting assigned anywhere.
> > >
> > > The above log is almost complete (lacked enabling the device afterwards).
> > >
> > > AFAIU, the BARs come from the reg and ranges properties in the
> > > PCI controller nodes;
> > > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
> >
> > Thanks, although I had already found this line by grep. I was just
> > expecting the address appear among root bus resources too.
> >
> > Curiously enough, pci_register_host_bridge() seems to try to add some
> > resource from that list into bus and it's what prints those "root bus
> > resource" lines and ee090000 is not among the printed lines despite
> > appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> > resources seems to be in disagreement and I'm not sure what to make of it.
> >
> > But before considering going into that direction or figuring out why this
> > ee090000 resource does not appear among root bus resources, could you
> > check if the attached patch changes behavior for the resource which are
> > non-zero based?
> 
> This patch has no impact on dmesg, lspci output, or /proc/iomem
> for pci-rcar-gen2.

It would have been too easy... :-(

I'm sorry I don't really know these platform well and I'm currently trying 
to understand what adds that ee090000 resource into the resource tree
and so far I've not been very successful.

Perhaps it would be easiest to print a stacktrace when the resource is 
added but there are many possible functions. I think all of them 
converge in __request_resource() so I suggest adding:

WARN_ON(new->start == 0xee090000);

before __request_resource() does anything.


-- 
 i.

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Geert Uytterhoeven]

Hi Ilpo,

On Thu, 2 Oct 2025 at 16:54, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > > > with IORESOURCE_UNSET.
> > > > > > >
> > > > > > > Resources that do not reside within their bridge window, however, are
> > > > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > > > conflicts detected in quirk_system_pci_resources():
> > > > > > >
> > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > > > ...
> > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > > > ...
> > > > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > >
> > > > > > > Mark resources that are not contained within their bridge window with
> > > > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > > > >
> > > > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > > >
> > > > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > > > linux-next/master next-20250929 pci/next
> > > >
> > > > > > This replaces the actual resources by their sizes in the boot log on
> > > > > > e.g. on R-Car M2-W:
> > > > > >
> > > > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > > > >
> > > > > What is going to be the parent of these resources? They don't seem to fall
> > > > > under the root bus resource above in which case the output change is
> > > > > intentional so they don't appear as if address range would be "okay".
> > > >
> > > > >From /proc/iomem:
> > > >
> > > >     ee080000-ee08ffff : pci@ee090000
> > > >       ee080000-ee080fff : 0000:00:01.0
> > > >         ee080000-ee080fff : ohci_hcd
> > > >       ee081000-ee0810ff : 0000:00:02.0
> > > >         ee081000-ee0810ff : ehci_hcd
> > > >     ee090000-ee090bff : ee090000.pci pci@ee090000
> > >
> > > Okay, so this seem to appear in the resource tree but not among the root
> > > bus resources.
> > >
> > > >     ee0c0000-ee0cffff : pci@ee0d0000
> > > >       ee0c0000-ee0c0fff : 0001:01:01.0
> > > >         ee0c0000-ee0c0fff : ohci_hcd
> > > >       ee0c1000-ee0c10ff : 0001:01:02.0
> > > >         ee0c1000-ee0c10ff : ehci_hcd
> > > >
> > > > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > > > and end addresses.
> > > >
> > > > Yeah, that's how I found this commit, without bisecting ;-)
> > > >
> > > > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > >
> > > > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > > > of the kernel to think that resource range valid and in use (in your
> > > > > case it's so small it wouldn't collide with anything but it wasn't
> > > > > properly set up resource, nonetheless).
> > > > >
> > > > > >      pci 0000:00:01.0: supports D1 D2
> > > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > >
> > > > > And this as well is very much intentional.
> > > > >
> > > > > >      pci 0000:00:02.0: supports D1 D2
> > > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > > >
> > > > > > Is that intentional?
> > > > >
> > > > > There's also that pci_dbg() in the patch which would show the original
> > > > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > > > making that pci_info() though so it would appear always.
> > > > >
> > > > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > > > getting assigned anywhere.
> > > >
> > > > The above log is almost complete (lacked enabling the device afterwards).
> > > >
> > > > AFAIU, the BARs come from the reg and ranges properties in the
> > > > PCI controller nodes;
> > > > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
> > >
> > > Thanks, although I had already found this line by grep. I was just
> > > expecting the address appear among root bus resources too.
> > >
> > > Curiously enough, pci_register_host_bridge() seems to try to add some
> > > resource from that list into bus and it's what prints those "root bus
> > > resource" lines and ee090000 is not among the printed lines despite
> > > appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> > > resources seems to be in disagreement and I'm not sure what to make of it.
> > >
> > > But before considering going into that direction or figuring out why this
> > > ee090000 resource does not appear among root bus resources, could you
> > > check if the attached patch changes behavior for the resource which are
> > > non-zero based?
> >
> > This patch has no impact on dmesg, lspci output, or /proc/iomem
> > for pci-rcar-gen2.
>
> It would have been too easy... :-(
>
> I'm sorry I don't really know these platform well and I'm currently trying
> to understand what adds that ee090000 resource into the resource tree
> and so far I've not been very successful.
>
> Perhaps it would be easiest to print a stacktrace when the resource is
> added but there are many possible functions. I think all of them
> converge in __request_resource() so I suggest adding:
>
> WARN_ON(new->start == 0xee090000);
>
> before __request_resource() does anything.

    Call trace:
     unwind_backtrace from show_stack+0x10/0x14
     show_stack from dump_stack_lvl+0x7c/0xb0
     dump_stack_lvl from __warn+0x80/0x198
     __warn from warn_slowpath_fmt+0xc0/0x124
     warn_slowpath_fmt from __request_resource+0x38/0xc8
     __request_resource from __request_region+0xc4/0x1e8
     __request_region from __devm_request_region+0x80/0xac
     __devm_request_region from __devm_ioremap_resource+0xcc/0x160
     __devm_ioremap_resource from rcar_pci_probe+0x58/0x350
     rcar_pci_probe from platform_probe+0x58/0x90

I.e. the call to devm_platform_get_and_ioremap_resource() in
drivers/pci/controller/pci-rcar-gen2.c:rcar_pci_probe().

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 13209 bytes --]

On Thu, 2 Oct 2025, Geert Uytterhoeven wrote:

> Hi Ilpo,
> 
> On Thu, 2 Oct 2025 at 16:54, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > > > > with IORESOURCE_UNSET.
> > > > > > > >
> > > > > > > > Resources that do not reside within their bridge window, however, are
> > > > > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > > > > conflicts detected in quirk_system_pci_resources():
> > > > > > > >
> > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > > > > ...
> > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > > > > ...
> > > > > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > >
> > > > > > > > Mark resources that are not contained within their bridge window with
> > > > > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > > > > >
> > > > > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > > > >
> > > > > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > > > > linux-next/master next-20250929 pci/next
> > > > >
> > > > > > > This replaces the actual resources by their sizes in the boot log on
> > > > > > > e.g. on R-Car M2-W:
> > > > > > >
> > > > > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > > > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > > > > >
> > > > > > What is going to be the parent of these resources? They don't seem to fall
> > > > > > under the root bus resource above in which case the output change is
> > > > > > intentional so they don't appear as if address range would be "okay".
> > > > >
> > > > > >From /proc/iomem:
> > > > >
> > > > >     ee080000-ee08ffff : pci@ee090000
> > > > >       ee080000-ee080fff : 0000:00:01.0
> > > > >         ee080000-ee080fff : ohci_hcd
> > > > >       ee081000-ee0810ff : 0000:00:02.0
> > > > >         ee081000-ee0810ff : ehci_hcd
> > > > >     ee090000-ee090bff : ee090000.pci pci@ee090000
> > > >
> > > > Okay, so this seem to appear in the resource tree but not among the root
> > > > bus resources.
> > > >
> > > > >     ee0c0000-ee0cffff : pci@ee0d0000
> > > > >       ee0c0000-ee0c0fff : 0001:01:01.0
> > > > >         ee0c0000-ee0c0fff : ohci_hcd
> > > > >       ee0c1000-ee0c10ff : 0001:01:02.0
> > > > >         ee0c1000-ee0c10ff : ehci_hcd
> > > > >
> > > > > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > > > > and end addresses.
> > > > >
> > > > > Yeah, that's how I found this commit, without bisecting ;-)
> > > > >
> > > > > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > > > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > > >
> > > > > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > > > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > > > > of the kernel to think that resource range valid and in use (in your
> > > > > > case it's so small it wouldn't collide with anything but it wasn't
> > > > > > properly set up resource, nonetheless).
> > > > > >
> > > > > > >      pci 0000:00:01.0: supports D1 D2
> > > > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > > > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > > >
> > > > > > And this as well is very much intentional.
> > > > > >
> > > > > > >      pci 0000:00:02.0: supports D1 D2
> > > > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > > > >
> > > > > > > Is that intentional?
> > > > > >
> > > > > > There's also that pci_dbg() in the patch which would show the original
> > > > > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > > > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > > > > making that pci_info() though so it would appear always.
> > > > > >
> > > > > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > > > > getting assigned anywhere.
> > > > >
> > > > > The above log is almost complete (lacked enabling the device afterwards).
> > > > >
> > > > > AFAIU, the BARs come from the reg and ranges properties in the
> > > > > PCI controller nodes;
> > > > > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
> > > >
> > > > Thanks, although I had already found this line by grep. I was just
> > > > expecting the address appear among root bus resources too.
> > > >
> > > > Curiously enough, pci_register_host_bridge() seems to try to add some
> > > > resource from that list into bus and it's what prints those "root bus
> > > > resource" lines and ee090000 is not among the printed lines despite
> > > > appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> > > > resources seems to be in disagreement and I'm not sure what to make of it.
> > > >
> > > > But before considering going into that direction or figuring out why this
> > > > ee090000 resource does not appear among root bus resources, could you
> > > > check if the attached patch changes behavior for the resource which are
> > > > non-zero based?
> > >
> > > This patch has no impact on dmesg, lspci output, or /proc/iomem
> > > for pci-rcar-gen2.
> >
> > It would have been too easy... :-(
> >
> > I'm sorry I don't really know these platform well and I'm currently trying
> > to understand what adds that ee090000 resource into the resource tree
> > and so far I've not been very successful.
> >
> > Perhaps it would be easiest to print a stacktrace when the resource is
> > added but there are many possible functions. I think all of them
> > converge in __request_resource() so I suggest adding:
> >
> > WARN_ON(new->start == 0xee090000);
> >
> > before __request_resource() does anything.
> 
>     Call trace:
>      unwind_backtrace from show_stack+0x10/0x14
>      show_stack from dump_stack_lvl+0x7c/0xb0
>      dump_stack_lvl from __warn+0x80/0x198
>      __warn from warn_slowpath_fmt+0xc0/0x124
>      warn_slowpath_fmt from __request_resource+0x38/0xc8
>      __request_resource from __request_region+0xc4/0x1e8
>      __request_region from __devm_request_region+0x80/0xac
>      __devm_request_region from __devm_ioremap_resource+0xcc/0x160
>      __devm_ioremap_resource from rcar_pci_probe+0x58/0x350
>      rcar_pci_probe from platform_probe+0x58/0x90
> 
> I.e. the call to devm_platform_get_and_ioremap_resource() in
> drivers/pci/controller/pci-rcar-gen2.c:rcar_pci_probe().

Thanks, the patch below might help BAR0 (but I'm not sure if it's the 
correct solution due to being so unfamiliar with these kind of platforms 
and how they're initialized).

If this works, we'll also have to decide what to do with the BAR1 (it 
didn't appear in your (partial?) /proc/iomem quote so I'm left unsure how 
to approach it).

I also noticed that || COMPILE_TEST is made ineffective for this driver by 
the depends on ARM on the other line but it built just fine on x86 after 
changing the depends on to:

depends on (ARCH_RENESAS && ARM) || COMPILE_TEST


--
[PATCH 1/1] PCI: rcar-gen2: Add BAR0 into host bridge resources

On R-Car M2-W, 0000:00:00.0 has BAR0 address that does not fall under
any root bus resource.

 pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
 pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
 pci-rcar-gen2 ee090000.pci: PCI: revision 11
 pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
 pci_bus 0000:00: root bus resource [bus 00]
 pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
 pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
 pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]

The same resource, however, appears in the resource tree (from
/proc/iomem):

ee090000-ee090bff : ee090000.pci pci@ee090000

This discrepancy between the resource tree and PCI bus resources for
the root bus causes issues with the commit 06b77d5647a4 ("PCI: Mark
resources IORESOURCE_UNSET when outside bridge windows") as BAR0 is
outside of any bus resource, and therefore marked with
IORESOURCE_UNSET.

The resource is added into the resource tree by rcar_pci_probe().
Add the resource also into host bridge resources.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
 drivers/pci/controller/pci-rcar-gen2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/pci-rcar-gen2.c b/drivers/pci/controller/pci-rcar-gen2.c
index d29866485361..72ed44fdcde4 100644
--- a/drivers/pci/controller/pci-rcar-gen2.c
+++ b/drivers/pci/controller/pci-rcar-gen2.c
@@ -294,6 +294,8 @@ static int rcar_pci_probe(struct platform_device *pdev)
 	if (IS_ERR(reg))
 		return PTR_ERR(reg);
 
+	pci_add_resource(&bridge->windows, cfg_res);
+
 	mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
 	if (!mem_res || !mem_res->start)
 		return -ENODEV;

base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
-- 
2.39.5

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Geert Uytterhoeven]

Hi Ilpo,

On Thu, 2 Oct 2025 at 18:59, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> On Thu, 2 Oct 2025, Geert Uytterhoeven wrote:
> > On Thu, 2 Oct 2025 at 16:54, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
> > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > > > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > > > > > with IORESOURCE_UNSET.
> > > > > > > > >
> > > > > > > > > Resources that do not reside within their bridge window, however, are
> > > > > > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > > > > > conflicts detected in quirk_system_pci_resources():
> > > > > > > > >
> > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > > > > > ...
> > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > > > > > ...
> > > > > > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > >
> > > > > > > > > Mark resources that are not contained within their bridge window with
> > > > > > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > > > > > >
> > > > > > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > > > > >
> > > > > > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > > > > > linux-next/master next-20250929 pci/next
> > > > > >
> > > > > > > > This replaces the actual resources by their sizes in the boot log on
> > > > > > > > e.g. on R-Car M2-W:
> > > > > > > >
> > > > > > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > > > > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > > > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > > > > > >
> > > > > > > What is going to be the parent of these resources? They don't seem to fall
> > > > > > > under the root bus resource above in which case the output change is
> > > > > > > intentional so they don't appear as if address range would be "okay".
> > > > > >
> > > > > > >From /proc/iomem:
> > > > > >
> > > > > >     ee080000-ee08ffff : pci@ee090000
> > > > > >       ee080000-ee080fff : 0000:00:01.0
> > > > > >         ee080000-ee080fff : ohci_hcd
> > > > > >       ee081000-ee0810ff : 0000:00:02.0
> > > > > >         ee081000-ee0810ff : ehci_hcd
> > > > > >     ee090000-ee090bff : ee090000.pci pci@ee090000
> > > > >
> > > > > Okay, so this seem to appear in the resource tree but not among the root
> > > > > bus resources.
> > > > >
> > > > > >     ee0c0000-ee0cffff : pci@ee0d0000
> > > > > >       ee0c0000-ee0c0fff : 0001:01:01.0
> > > > > >         ee0c0000-ee0c0fff : ohci_hcd
> > > > > >       ee0c1000-ee0c10ff : 0001:01:02.0
> > > > > >         ee0c1000-ee0c10ff : ehci_hcd
> > > > > >
> > > > > > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > > > > > and end addresses.
> > > > > >
> > > > > > Yeah, that's how I found this commit, without bisecting ;-)
> > > > > >
> > > > > > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > > > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > > > > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > > > >
> > > > > > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > > > > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > > > > > of the kernel to think that resource range valid and in use (in your
> > > > > > > case it's so small it wouldn't collide with anything but it wasn't
> > > > > > > properly set up resource, nonetheless).
> > > > > > >
> > > > > > > >      pci 0000:00:01.0: supports D1 D2
> > > > > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > > > > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > > > >
> > > > > > > And this as well is very much intentional.
> > > > > > >
> > > > > > > >      pci 0000:00:02.0: supports D1 D2
> > > > > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > > > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > > > > >
> > > > > > > > Is that intentional?
> > > > > > >
> > > > > > > There's also that pci_dbg() in the patch which would show the original
> > > > > > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > > > > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > > > > > making that pci_info() though so it would appear always.
> > > > > > >
> > > > > > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > > > > > getting assigned anywhere.
> > > > > >
> > > > > > The above log is almost complete (lacked enabling the device afterwards).
> > > > > >
> > > > > > AFAIU, the BARs come from the reg and ranges properties in the
> > > > > > PCI controller nodes;
> > > > > > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
> > > > >
> > > > > Thanks, although I had already found this line by grep. I was just
> > > > > expecting the address appear among root bus resources too.
> > > > >
> > > > > Curiously enough, pci_register_host_bridge() seems to try to add some
> > > > > resource from that list into bus and it's what prints those "root bus
> > > > > resource" lines and ee090000 is not among the printed lines despite
> > > > > appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> > > > > resources seems to be in disagreement and I'm not sure what to make of it.
> > > > >
> > > > > But before considering going into that direction or figuring out why this
> > > > > ee090000 resource does not appear among root bus resources, could you
> > > > > check if the attached patch changes behavior for the resource which are
> > > > > non-zero based?
> > > >
> > > > This patch has no impact on dmesg, lspci output, or /proc/iomem
> > > > for pci-rcar-gen2.
> > >
> > > It would have been too easy... :-(
> > >
> > > I'm sorry I don't really know these platform well and I'm currently trying
> > > to understand what adds that ee090000 resource into the resource tree
> > > and so far I've not been very successful.
> > >
> > > Perhaps it would be easiest to print a stacktrace when the resource is
> > > added but there are many possible functions. I think all of them
> > > converge in __request_resource() so I suggest adding:
> > >
> > > WARN_ON(new->start == 0xee090000);
> > >
> > > before __request_resource() does anything.
> >
> >     Call trace:
> >      unwind_backtrace from show_stack+0x10/0x14
> >      show_stack from dump_stack_lvl+0x7c/0xb0
> >      dump_stack_lvl from __warn+0x80/0x198
> >      __warn from warn_slowpath_fmt+0xc0/0x124
> >      warn_slowpath_fmt from __request_resource+0x38/0xc8
> >      __request_resource from __request_region+0xc4/0x1e8
> >      __request_region from __devm_request_region+0x80/0xac
> >      __devm_request_region from __devm_ioremap_resource+0xcc/0x160
> >      __devm_ioremap_resource from rcar_pci_probe+0x58/0x350
> >      rcar_pci_probe from platform_probe+0x58/0x90
> >
> > I.e. the call to devm_platform_get_and_ioremap_resource() in
> > drivers/pci/controller/pci-rcar-gen2.c:rcar_pci_probe().
>
> Thanks, the patch below might help BAR0 (but I'm not sure if it's the
> correct solution due to being so unfamiliar with these kind of platforms
> and how they're initialized).

Thanks, that has the following impact on dmesg:

     pci-rcar-gen2 ee090000.pci: PCI: revision 11
     pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
     pci_bus 0000:00: root bus resource [bus 00]
    -pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
    +pci_bus 0000:00: root bus resource [mem 0xee080000-0xee090bff]
     pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
PCI endpoint
    -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
claim (no window)
    -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
    -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
initial claim (no window)
    +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
     pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
     pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
PCI endpoint
    -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
claim (no window)
     pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
     pci 0000:00:01.0: supports D1 D2
     pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
     pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
PCI endpoint
    -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
claim (no window)
     pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
     pci 0000:00:02.0: supports D1 D2
     pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
     PCI: bus0: Fast back to back transfers disabled
     pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
     pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
    -pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
    +pci_bus 0000:00: resource 4 [mem 0xee080000-0xee090bff]
     pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
     PM: genpd_add_device: Add ee0d0000.pci to always-on
     pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
    @@ -414,26 +416,22 @@ PM: ==== always-on/ee0d0000.pci: start
     pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
     pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
     pci_bus 0001:01: root bus resource [bus 01]
    -pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
    +pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0d0bff]
     pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional
PCI endpoint
    -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial
claim (no window)
    -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
    -pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
initial claim (no window)
    +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
     pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
     pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional
PCI endpoint
    -pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
claim (no window)
     pci 0001:01:01.0: BAR 0 [mem size 0x00001000]
     pci 0001:01:01.0: supports D1 D2
     pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
     pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
PCI endpoint
    -pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
claim (no window)
     pci 0001:01:02.0: BAR 0 [mem size 0x00000100]
     pci 0001:01:02.0: supports D1 D2
     pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
     PCI: bus1: Fast back to back transfers disabled
     pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
     pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
    -pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
    +pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0d0bff]
     rcar-pcie fe000000.pcie: adding to PM domain always-on
     PM: genpd_add_device: Add fe000000.pcie to always-on
     rcar-pcie fe000000.pcie: host bridge /soc/pcie@fe000000 ranges:

and on /proc/iomem (I used "diff -w" to reduce clutter):

     ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
     ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
     ec740000-ec7401ff : ec500000.sound audmapp
    -ee080000-ee08ffff : pci@ee090000
    -  ee080000-ee080fff : 0000:00:01.0
         ee080000-ee080fff : ohci_hcd
    -  ee081000-ee0810ff : 0000:00:02.0
         ee081000-ee0810ff : ehci_hcd
     ee090000-ee090bff : ee090000.pci pci@ee090000
    -ee0c0000-ee0cffff : pci@ee0d0000
    -  ee0c0000-ee0c0fff : 0001:01:01.0
         ee0c0000-ee0c0fff : ohci_hcd
    -  ee0c1000-ee0c10ff : 0001:01:02.0
         ee0c1000-ee0c10ff : ehci_hcd
     ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
     ee100000-ee100327 : ee100000.mmc mmc@ee100000

Removing the pci@ee0x0000 and 000x:0x:0x.0 entries doesn't look
right to me? Or am I missing something?

> If this works, we'll also have to decide what to do with the BAR1 (it
> didn't appear in your (partial?) /proc/iomem quote so I'm left unsure how
> to approach it).

That is indeed not visible in /proc/iomem.

I tried the following (whitespace-damaged):

--- a/drivers/pci/controller/pci-rcar-gen2.c
+++ b/drivers/pci/controller/pci-rcar-gen2.c
@@ -179,6 +179,7 @@ static void rcar_pci_setup(struct rcar_pci *priv)
        unsigned long window_size;
        unsigned long window_addr;
        unsigned long window_pci;
+       struct resource res;
        u32 val;

        entry = resource_list_first_type(&bridge->dma_ranges, IORESOURCE_MEM);
@@ -191,6 +192,8 @@ static void rcar_pci_setup(struct rcar_pci *priv)
                window_pci = entry->res->start - entry->offset;
                window_size = resource_size(entry->res);
        }
+       resource_set_range(&res, window_addr, window_size);
+       pci_add_resource(&bridge->windows, &res);

        pm_runtime_enable(dev);
        pm_runtime_get_sync(dev);

and only got:

     pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
     pci_bus 0000:00: root bus resource [bus 00]
     pci_bus 0000:00: root bus resource [mem 0xee080000-0xee090bff]
    +pci_bus 0000:00: busn_res: can not insert [bus 00-7fffffff] under
domain [bus 00-ff] (conflicts with (null) [bus 00-ff])
    +pci_bus 0000:00: root bus resource [mem size 0x40000000 64bit
pref window disabled]
     pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
PCI endpoint
     pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
     pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
    @@ -417,6 +419,8 @@ pci-rcar-gen2 ee0d0000.pci: PCI: revisio
     pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
     pci_bus 0001:01: root bus resource [bus 01]
     pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0d0bff]
    +pci_bus 0001:01: busn_res: can not insert [bus 01-7fffffff] under
domain [bus 00-ff] (conflicts with (null) [bus 00-ff])
    +pci_bus 0001:01: root bus resource [mem size 0x40000000 64bit
pref window disabled]
     pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional
PCI endpoint
     pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
     pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]

but no impact on /proc/iomem.

> I also noticed that || COMPILE_TEST is made ineffective for this driver by
> the depends on ARM on the other line but it built just fine on x86 after
> changing the depends on to:
>
> depends on (ARCH_RENESAS && ARM) || COMPILE_TEST

Thanks, that is a relic from the past, when the driver failed to build
on other architectures. I have submitted a fix.


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 21093 bytes --]

On Fri, 3 Oct 2025, Geert Uytterhoeven wrote:
> On Thu, 2 Oct 2025 at 18:59, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Thu, 2 Oct 2025, Geert Uytterhoeven wrote:
> > > On Thu, 2 Oct 2025 at 16:54, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
> > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > > > > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > > > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > > > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > > > > > > with IORESOURCE_UNSET.
> > > > > > > > > >
> > > > > > > > > > Resources that do not reside within their bridge window, however, are
> > > > > > > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > > > > > > conflicts detected in quirk_system_pci_resources():
> > > > > > > > > >
> > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > > > > > > ...
> > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > > > > > > ...
> > > > > > > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > > > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > >
> > > > > > > > > > Mark resources that are not contained within their bridge window with
> > > > > > > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > > > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > > > > > > >
> > > > > > > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > > > > > >
> > > > > > > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > > > > > > linux-next/master next-20250929 pci/next
> > > > > > >
> > > > > > > > > This replaces the actual resources by their sizes in the boot log on
> > > > > > > > > e.g. on R-Car M2-W:
> > > > > > > > >
> > > > > > > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > > > > > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > > > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > > > > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > > > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > > > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > > > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > > > > > > >
> > > > > > > > What is going to be the parent of these resources? They don't seem to fall
> > > > > > > > under the root bus resource above in which case the output change is
> > > > > > > > intentional so they don't appear as if address range would be "okay".
> > > > > > >
> > > > > > > >From /proc/iomem:
> > > > > > >
> > > > > > >     ee080000-ee08ffff : pci@ee090000
> > > > > > >       ee080000-ee080fff : 0000:00:01.0
> > > > > > >         ee080000-ee080fff : ohci_hcd
> > > > > > >       ee081000-ee0810ff : 0000:00:02.0
> > > > > > >         ee081000-ee0810ff : ehci_hcd
> > > > > > >     ee090000-ee090bff : ee090000.pci pci@ee090000
> > > > > >
> > > > > > Okay, so this seem to appear in the resource tree but not among the root
> > > > > > bus resources.
> > > > > >
> > > > > > >     ee0c0000-ee0cffff : pci@ee0d0000
> > > > > > >       ee0c0000-ee0c0fff : 0001:01:01.0
> > > > > > >         ee0c0000-ee0c0fff : ohci_hcd
> > > > > > >       ee0c1000-ee0c10ff : 0001:01:02.0
> > > > > > >         ee0c1000-ee0c10ff : ehci_hcd
> > > > > > >
> > > > > > > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > > > > > > and end addresses.
> > > > > > >
> > > > > > > Yeah, that's how I found this commit, without bisecting ;-)
> > > > > > >
> > > > > > > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > > > > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > > > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > > > > > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > > > > >
> > > > > > > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > > > > > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > > > > > > of the kernel to think that resource range valid and in use (in your
> > > > > > > > case it's so small it wouldn't collide with anything but it wasn't
> > > > > > > > properly set up resource, nonetheless).
> > > > > > > >
> > > > > > > > >      pci 0000:00:01.0: supports D1 D2
> > > > > > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > > > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > > > > > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > > > > >
> > > > > > > > And this as well is very much intentional.
> > > > > > > >
> > > > > > > > >      pci 0000:00:02.0: supports D1 D2
> > > > > > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > > > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > > > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > > > > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > > > > > >
> > > > > > > > > Is that intentional?
> > > > > > > >
> > > > > > > > There's also that pci_dbg() in the patch which would show the original
> > > > > > > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > > > > > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > > > > > > making that pci_info() though so it would appear always.
> > > > > > > >
> > > > > > > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > > > > > > getting assigned anywhere.
> > > > > > >
> > > > > > > The above log is almost complete (lacked enabling the device afterwards).
> > > > > > >
> > > > > > > AFAIU, the BARs come from the reg and ranges properties in the
> > > > > > > PCI controller nodes;
> > > > > > > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
> > > > > >
> > > > > > Thanks, although I had already found this line by grep. I was just
> > > > > > expecting the address appear among root bus resources too.
> > > > > >
> > > > > > Curiously enough, pci_register_host_bridge() seems to try to add some
> > > > > > resource from that list into bus and it's what prints those "root bus
> > > > > > resource" lines and ee090000 is not among the printed lines despite
> > > > > > appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> > > > > > resources seems to be in disagreement and I'm not sure what to make of it.
> > > > > >
> > > > > > But before considering going into that direction or figuring out why this
> > > > > > ee090000 resource does not appear among root bus resources, could you
> > > > > > check if the attached patch changes behavior for the resource which are
> > > > > > non-zero based?
> > > > >
> > > > > This patch has no impact on dmesg, lspci output, or /proc/iomem
> > > > > for pci-rcar-gen2.
> > > >
> > > > It would have been too easy... :-(
> > > >
> > > > I'm sorry I don't really know these platform well and I'm currently trying
> > > > to understand what adds that ee090000 resource into the resource tree
> > > > and so far I've not been very successful.
> > > >
> > > > Perhaps it would be easiest to print a stacktrace when the resource is
> > > > added but there are many possible functions. I think all of them
> > > > converge in __request_resource() so I suggest adding:
> > > >
> > > > WARN_ON(new->start == 0xee090000);
> > > >
> > > > before __request_resource() does anything.
> > >
> > >     Call trace:
> > >      unwind_backtrace from show_stack+0x10/0x14
> > >      show_stack from dump_stack_lvl+0x7c/0xb0
> > >      dump_stack_lvl from __warn+0x80/0x198
> > >      __warn from warn_slowpath_fmt+0xc0/0x124
> > >      warn_slowpath_fmt from __request_resource+0x38/0xc8
> > >      __request_resource from __request_region+0xc4/0x1e8
> > >      __request_region from __devm_request_region+0x80/0xac
> > >      __devm_request_region from __devm_ioremap_resource+0xcc/0x160
> > >      __devm_ioremap_resource from rcar_pci_probe+0x58/0x350
> > >      rcar_pci_probe from platform_probe+0x58/0x90
> > >
> > > I.e. the call to devm_platform_get_and_ioremap_resource() in
> > > drivers/pci/controller/pci-rcar-gen2.c:rcar_pci_probe().
> >
> > Thanks, the patch below might help BAR0 (but I'm not sure if it's the
> > correct solution due to being so unfamiliar with these kind of platforms
> > and how they're initialized).
> 
> Thanks, that has the following impact on dmesg:
> 
>      pci-rcar-gen2 ee090000.pci: PCI: revision 11
>      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
>      pci_bus 0000:00: root bus resource [bus 00]
>     -pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
>     +pci_bus 0000:00: root bus resource [mem 0xee080000-0xee090bff]
>      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
> PCI endpoint
>     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
> claim (no window)
>     -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
>     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> initial claim (no window)
>     +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
>      pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
>      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> PCI endpoint
>     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
> claim (no window)
>      pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
>      pci 0000:00:01.0: supports D1 D2
>      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
>      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
> PCI endpoint
>     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
> claim (no window)

Did you e.g. forget to change pci_dbg() to pci_info() as these all went 
away, I cannot see why it should disappear because of my patch?

(No need to apologize if that was the case, just confirming if that 
explains it is enough. :-))

>      pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
>      pci 0000:00:02.0: supports D1 D2
>      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
>      PCI: bus0: Fast back to back transfers disabled
>      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
>      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned

Perhaps print here what's the parent resource of these resource.

>     -pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
>     +pci_bus 0000:00: resource 4 [mem 0xee080000-0xee090bff]
>      pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
>      PM: genpd_add_device: Add ee0d0000.pci to always-on
>      pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
>     @@ -414,26 +416,22 @@ PM: ==== always-on/ee0d0000.pci: start
>      pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
>      pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
>      pci_bus 0001:01: root bus resource [bus 01]
>     -pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
>     +pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0d0bff]
>      pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional
> PCI endpoint
>     -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial
> claim (no window)
>     -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
>     -pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> initial claim (no window)
>     +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
>      pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
>      pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> PCI endpoint
>     -pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
> claim (no window)
>      pci 0001:01:01.0: BAR 0 [mem size 0x00001000]
>      pci 0001:01:01.0: supports D1 D2
>      pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
>      pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
> PCI endpoint
>     -pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
> claim (no window)
>      pci 0001:01:02.0: BAR 0 [mem size 0x00000100]
>      pci 0001:01:02.0: supports D1 D2
>      pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
>      PCI: bus1: Fast back to back transfers disabled
>      pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
>      pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
>     -pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
>     +pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0d0bff]
>      rcar-pcie fe000000.pcie: adding to PM domain always-on
>      PM: genpd_add_device: Add fe000000.pcie to always-on
>      rcar-pcie fe000000.pcie: host bridge /soc/pcie@fe000000 ranges:
> 
> and on /proc/iomem (I used "diff -w" to reduce clutter):
> 
>      ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
>      ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
>      ec740000-ec7401ff : ec500000.sound audmapp
>     -ee080000-ee08ffff : pci@ee090000

So what did add this previous? (Maybe use the same WARN_ON() trick as 
previously to find out.)

It might have gotten broken because the coalesed resource 
ee080000-ee090bff overlaps with that other resource in the resource tree. 
But I don't see anything to that effect in the log so it's either silent 
failure or there's much filtered from the log.

>     -  ee080000-ee080fff : 0000:00:01.0
>          ee080000-ee080fff : ohci_hcd
>     -  ee081000-ee0810ff : 0000:00:02.0
>          ee081000-ee0810ff : ehci_hcd
>      ee090000-ee090bff : ee090000.pci pci@ee090000
>     -ee0c0000-ee0cffff : pci@ee0d0000
>     -  ee0c0000-ee0c0fff : 0001:01:01.0
>          ee0c0000-ee0c0fff : ohci_hcd
>     -  ee0c1000-ee0c10ff : 0001:01:02.0
>          ee0c1000-ee0c10ff : ehci_hcd
>      ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
>      ee100000-ee100327 : ee100000.mmc mmc@ee100000
> 
> Removing the pci@ee0x0000 and 000x:0x:0x.0 entries doesn't look
> right to me? Or am I missing something?

I cannot understand this output, these resources seem to have been now 
left without a parent and due to -w I don't know what's their real 
indentation level.

> > If this works, we'll also have to decide what to do with the BAR1 (it
> > didn't appear in your (partial?) /proc/iomem quote so I'm left unsure how
> > to approach it).
> 
> That is indeed not visible in /proc/iomem.

I meant before the commit 06b77d5647a4d6a7 ("PCI Mark resources 
IORESOURCE_UNSET when outside bridge windows"), was it present?

> I tried the following (whitespace-damaged):
> 
> --- a/drivers/pci/controller/pci-rcar-gen2.c
> +++ b/drivers/pci/controller/pci-rcar-gen2.c
> @@ -179,6 +179,7 @@ static void rcar_pci_setup(struct rcar_pci *priv)
>         unsigned long window_size;
>         unsigned long window_addr;
>         unsigned long window_pci;
> +       struct resource res;
>         u32 val;
> 
>         entry = resource_list_first_type(&bridge->dma_ranges, IORESOURCE_MEM);
> @@ -191,6 +192,8 @@ static void rcar_pci_setup(struct rcar_pci *priv)
>                 window_pci = entry->res->start - entry->offset;
>                 window_size = resource_size(entry->res);
>         }
> +       resource_set_range(&res, window_addr, window_size);

You need to set flags properly too as this now tried to insert BUS, not 
MEM resource (DEFINE_RES() might be the more appropriate in that case 
anyway). 

However, if there's not &bridge->dma_ranges ranges entry, rcar_pci_setup() 
seems to initialize the resource to 0x40000000-0x7fffffff and I'm not sure 
how it's supposed to work if there's more than one of these devices as per 
the log above.

> +       pci_add_resource(&bridge->windows, &res);

What would be the backing resource in the resource tree for this? I'm not 
sure if pci_add_resource() is going to result in adding one into the 
resource tree.

>         pm_runtime_enable(dev);
>         pm_runtime_get_sync(dev);
> 
> and only got:
> 
>      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
>      pci_bus 0000:00: root bus resource [bus 00]
>      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee090bff]
>     +pci_bus 0000:00: busn_res: can not insert [bus 00-7fffffff] under
> domain [bus 00-ff] (conflicts with (null) [bus 00-ff])
>     +pci_bus 0000:00: root bus resource [mem size 0x40000000 64bit
> pref window disabled]
>      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
> PCI endpoint
>      pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
>      pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
>     @@ -417,6 +419,8 @@ pci-rcar-gen2 ee0d0000.pci: PCI: revisio
>      pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
>      pci_bus 0001:01: root bus resource [bus 01]
>      pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0d0bff]
>     +pci_bus 0001:01: busn_res: can not insert [bus 01-7fffffff] under
> domain [bus 00-ff] (conflicts with (null) [bus 00-ff])
>     +pci_bus 0001:01: root bus resource [mem size 0x40000000 64bit
> pref window disabled]
>      pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional
> PCI endpoint
>      pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
>      pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
> 
> but no impact on /proc/iomem.
> 
> > I also noticed that || COMPILE_TEST is made ineffective for this driver by
> > the depends on ARM on the other line but it built just fine on x86 after
> > changing the depends on to:
> >
> > depends on (ARCH_RENESAS && ARM) || COMPILE_TEST
> 
> Thanks, that is a relic from the past, when the driver failed to build
> on other architectures. I have submitted a fix.

Thanks.

-- 
 i.

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Geert Uytterhoeven]

Hi Ilpo,

On Fri, 3 Oct 2025 at 16:58, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> On Fri, 3 Oct 2025, Geert Uytterhoeven wrote:
> > On Thu, 2 Oct 2025 at 18:59, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > On Thu, 2 Oct 2025, Geert Uytterhoeven wrote:
> > > > On Thu, 2 Oct 2025 at 16:54, Ilpo Järvinen
> > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
> > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > > > > > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > > > > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > > > > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > > > > > > > with IORESOURCE_UNSET.
> > > > > > > > > > >
> > > > > > > > > > > Resources that do not reside within their bridge window, however, are
> > > > > > > > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > > > > > > > conflicts detected in quirk_system_pci_resources():
> > > > > > > > > > >
> > > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > > > > > > > ...
> > > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > > > > > > > ...
> > > > > > > > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > > > > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > >
> > > > > > > > > > > Mark resources that are not contained within their bridge window with
> > > > > > > > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > > > > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > > > > > > > >
> > > > > > > > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > > > > > > >
> > > > > > > > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > > > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > > > > > > > linux-next/master next-20250929 pci/next
> > > > > > > >
> > > > > > > > > > This replaces the actual resources by their sizes in the boot log on
> > > > > > > > > > e.g. on R-Car M2-W:
> > > > > > > > > >
> > > > > > > > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > > > > > > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > > > > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > > > > > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > > > > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > > > > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > > > > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > > > > > > > >
> > > > > > > > > What is going to be the parent of these resources? They don't seem to fall
> > > > > > > > > under the root bus resource above in which case the output change is
> > > > > > > > > intentional so they don't appear as if address range would be "okay".
> > > > > > > >
> > > > > > > > >From /proc/iomem:
> > > > > > > >
> > > > > > > >     ee080000-ee08ffff : pci@ee090000
> > > > > > > >       ee080000-ee080fff : 0000:00:01.0
> > > > > > > >         ee080000-ee080fff : ohci_hcd
> > > > > > > >       ee081000-ee0810ff : 0000:00:02.0
> > > > > > > >         ee081000-ee0810ff : ehci_hcd
> > > > > > > >     ee090000-ee090bff : ee090000.pci pci@ee090000
> > > > > > >
> > > > > > > Okay, so this seem to appear in the resource tree but not among the root
> > > > > > > bus resources.
> > > > > > >
> > > > > > > >     ee0c0000-ee0cffff : pci@ee0d0000
> > > > > > > >       ee0c0000-ee0c0fff : 0001:01:01.0
> > > > > > > >         ee0c0000-ee0c0fff : ohci_hcd
> > > > > > > >       ee0c1000-ee0c10ff : 0001:01:02.0
> > > > > > > >         ee0c1000-ee0c10ff : ehci_hcd
> > > > > > > >
> > > > > > > > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > > > > > > > and end addresses.
> > > > > > > >
> > > > > > > > Yeah, that's how I found this commit, without bisecting ;-)
> > > > > > > >
> > > > > > > > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > > > > > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > > > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > > > > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > > > > > > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > > > > > >
> > > > > > > > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > > > > > > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > > > > > > > of the kernel to think that resource range valid and in use (in your
> > > > > > > > > case it's so small it wouldn't collide with anything but it wasn't
> > > > > > > > > properly set up resource, nonetheless).
> > > > > > > > >
> > > > > > > > > >      pci 0000:00:01.0: supports D1 D2
> > > > > > > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > > > > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > > > > > > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > > > > > >
> > > > > > > > > And this as well is very much intentional.
> > > > > > > > >
> > > > > > > > > >      pci 0000:00:02.0: supports D1 D2
> > > > > > > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > > > > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > > > > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > > > > > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > > > > > > >
> > > > > > > > > > Is that intentional?
> > > > > > > > >
> > > > > > > > > There's also that pci_dbg() in the patch which would show the original
> > > > > > > > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > > > > > > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > > > > > > > making that pci_info() though so it would appear always.
> > > > > > > > >
> > > > > > > > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > > > > > > > getting assigned anywhere.
> > > > > > > >
> > > > > > > > The above log is almost complete (lacked enabling the device afterwards).
> > > > > > > >
> > > > > > > > AFAIU, the BARs come from the reg and ranges properties in the
> > > > > > > > PCI controller nodes;
> > > > > > > > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
> > > > > > >
> > > > > > > Thanks, although I had already found this line by grep. I was just
> > > > > > > expecting the address appear among root bus resources too.
> > > > > > >
> > > > > > > Curiously enough, pci_register_host_bridge() seems to try to add some
> > > > > > > resource from that list into bus and it's what prints those "root bus
> > > > > > > resource" lines and ee090000 is not among the printed lines despite
> > > > > > > appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> > > > > > > resources seems to be in disagreement and I'm not sure what to make of it.
> > > > > > >
> > > > > > > But before considering going into that direction or figuring out why this
> > > > > > > ee090000 resource does not appear among root bus resources, could you
> > > > > > > check if the attached patch changes behavior for the resource which are
> > > > > > > non-zero based?
> > > > > >
> > > > > > This patch has no impact on dmesg, lspci output, or /proc/iomem
> > > > > > for pci-rcar-gen2.
> > > > >
> > > > > It would have been too easy... :-(
> > > > >
> > > > > I'm sorry I don't really know these platform well and I'm currently trying
> > > > > to understand what adds that ee090000 resource into the resource tree
> > > > > and so far I've not been very successful.
> > > > >
> > > > > Perhaps it would be easiest to print a stacktrace when the resource is
> > > > > added but there are many possible functions. I think all of them
> > > > > converge in __request_resource() so I suggest adding:
> > > > >
> > > > > WARN_ON(new->start == 0xee090000);
> > > > >
> > > > > before __request_resource() does anything.
> > > >
> > > >     Call trace:
> > > >      unwind_backtrace from show_stack+0x10/0x14
> > > >      show_stack from dump_stack_lvl+0x7c/0xb0
> > > >      dump_stack_lvl from __warn+0x80/0x198
> > > >      __warn from warn_slowpath_fmt+0xc0/0x124
> > > >      warn_slowpath_fmt from __request_resource+0x38/0xc8
> > > >      __request_resource from __request_region+0xc4/0x1e8
> > > >      __request_region from __devm_request_region+0x80/0xac
> > > >      __devm_request_region from __devm_ioremap_resource+0xcc/0x160
> > > >      __devm_ioremap_resource from rcar_pci_probe+0x58/0x350
> > > >      rcar_pci_probe from platform_probe+0x58/0x90
> > > >
> > > > I.e. the call to devm_platform_get_and_ioremap_resource() in
> > > > drivers/pci/controller/pci-rcar-gen2.c:rcar_pci_probe().
> > >
> > > Thanks, the patch below might help BAR0 (but I'm not sure if it's the
> > > correct solution due to being so unfamiliar with these kind of platforms
> > > and how they're initialized).
> >
> > Thanks, that has the following impact on dmesg:
> >
> >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> >      pci_bus 0000:00: root bus resource [bus 00]
> >     -pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> >     +pci_bus 0000:00: root bus resource [mem 0xee080000-0xee090bff]
> >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
> > PCI endpoint
> >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
> > claim (no window)
> >     -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> > initial claim (no window)
> >     +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> >      pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> > PCI endpoint
> >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
> > claim (no window)
> >      pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> >      pci 0000:00:01.0: supports D1 D2
> >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
> > PCI endpoint
> >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
> > claim (no window)
>
> Did you e.g. forget to change pci_dbg() to pci_info() as these all went
> away, I cannot see why it should disappear because of my patch?
>
> (No need to apologize if that was the case, just confirming if that
> explains it is enough. :-))

I indeed dropped that change. Adding it back...

> >      pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> >      pci 0000:00:02.0: supports D1 D2
> >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> >      PCI: bus0: Fast back to back transfers disabled
> >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
>
> Perhaps print here what's the parent resource of these resource.

pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned (parent
[mem 0xee080000-0xee08ffff])
pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned (parent
[mem 0xee080000-0xee08ffff])

>
> >     -pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> >     +pci_bus 0000:00: resource 4 [mem 0xee080000-0xee090bff]
> >      pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
> >      PM: genpd_add_device: Add ee0d0000.pci to always-on
> >      pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
> >     @@ -414,26 +416,22 @@ PM: ==== always-on/ee0d0000.pci: start
> >      pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
> >      pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
> >      pci_bus 0001:01: root bus resource [bus 01]
> >     -pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
> >     +pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0d0bff]
> >      pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> >     -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial claim (no window)
> >     -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
> >     -pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no initial claim (no window)
> >     +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
> >      pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
> >      pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> >     -pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial claim (no window)
> >      pci 0001:01:01.0: BAR 0 [mem size 0x00001000]
> >      pci 0001:01:01.0: supports D1 D2
> >      pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
> >      pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> >     -pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial claim (no window)
> >      pci 0001:01:02.0: BAR 0 [mem size 0x00000100]
> >      pci 0001:01:02.0: supports D1 D2
> >      pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
> >      PCI: bus1: Fast back to back transfers disabled
> >      pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
> >      pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
> >     -pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
> >     +pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0d0bff]
> >      rcar-pcie fe000000.pcie: adding to PM domain always-on
> >      PM: genpd_add_device: Add fe000000.pcie to always-on
> >      rcar-pcie fe000000.pcie: host bridge /soc/pcie@fe000000 ranges:
> >
> > and on /proc/iomem (I used "diff -w" to reduce clutter):
> >
> >      ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
> >      ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
> >      ec740000-ec7401ff : ec500000.sound audmapp
> >     -ee080000-ee08ffff : pci@ee090000
>
> So what did add this previous? (Maybe use the same WARN_ON() trick as
> previously to find out.)

First call:

    + __request_resource from request_resource_conflict+0x24/0x3c
    + request_resource_conflict from devm_request_resource+0x48/0x9c
    + devm_request_resource from devm_request_pci_bus_resources+0x5c/0x70
    + devm_request_pci_bus_resources from devm_of_pci_bridge_init+0x7c/0x1c0
    + devm_of_pci_bridge_init from devm_pci_alloc_host_bridge+0x44/0x6c
    + devm_pci_alloc_host_bridge from rcar_pci_probe+0x34/0x384
    + rcar_pci_probe from platform_probe+0x58/0x90

Second call:

    + __request_resource from allocate_resource+0x1b8/0x1d4
    + allocate_resource from pci_bus_alloc_from_region+0x1e0/0x220
    + pci_bus_alloc_from_region from pci_bus_alloc_resource+0x84/0xb8
    + pci_bus_alloc_resource from _pci_assign_resource+0x78/0x150
    + _pci_assign_resource from pci_assign_resource+0x10c/0x310
    + pci_assign_resource from assign_requested_resources_sorted+0x78/0xac
    + assign_requested_resources_sorted from
__assign_resources_sorted+0x74/0x5c4
    + __assign_resources_sorted from __pci_bus_assign_resources+0x50/0x1f0
    + __pci_bus_assign_resources from
pci_assign_unassigned_root_bus_resources+0xa8/0x190
    + pci_assign_unassigned_root_bus_resources from pci_host_probe+0x5c/0xb0
    + pci_host_probe from rcar_pci_probe+0x2e0/0x384
    + rcar_pci_probe from platform_probe+0x58/0x90

Third call:

    + __request_resource from __request_region+0xc4/0x1e8
    + __request_region from __devm_request_region+0x80/0xac
    + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
    + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
    + pci_device_probe from really_probe+0x128/0x28c

Fourth call:

    + __request_region from __devm_request_region+0x80/0xac
    + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
    + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
    + pci_device_probe from really_probe+0x128/0x28c

Fifth call:

    + __request_region from __devm_request_region+0x80/0xac
    + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
    + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
    + pci_device_probe from really_probe+0x128/0x28c

> It might have gotten broken because the coalesed resource
> ee080000-ee090bff overlaps with that other resource in the resource tree.
> But I don't see anything to that effect in the log so it's either silent
> failure or there's much filtered from the log.
>
> >     -  ee080000-ee080fff : 0000:00:01.0
> >          ee080000-ee080fff : ohci_hcd
> >     -  ee081000-ee0810ff : 0000:00:02.0
> >          ee081000-ee0810ff : ehci_hcd
> >      ee090000-ee090bff : ee090000.pci pci@ee090000
> >     -ee0c0000-ee0cffff : pci@ee0d0000
> >     -  ee0c0000-ee0c0fff : 0001:01:01.0
> >          ee0c0000-ee0c0fff : ohci_hcd
> >     -  ee0c1000-ee0c10ff : 0001:01:02.0
> >          ee0c1000-ee0c10ff : ehci_hcd
> >      ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
> >      ee100000-ee100327 : ee100000.mmc mmc@ee100000
> >
> > Removing the pci@ee0x0000 and 000x:0x:0x.0 entries doesn't look
> > right to me? Or am I missing something?
>
> I cannot understand this output, these resources seem to have been now
> left without a parent and due to -w I don't know what's their real
> indentation level.

The *_hcd resources are now at the top level.

     ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
     ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
     ec740000-ec7401ff : ec500000.sound audmapp
    -ee080000-ee08ffff : pci@ee090000
    -  ee080000-ee080fff : 0000:00:01.0
    -    ee080000-ee080fff : ohci_hcd
    -  ee081000-ee0810ff : 0000:00:02.0
    -    ee081000-ee0810ff : ehci_hcd
    +ee080000-ee080fff : ohci_hcd
    +ee081000-ee0810ff : ehci_hcd
     ee090000-ee090bff : ee090000.pci pci@ee090000
    -ee0c0000-ee0cffff : pci@ee0d0000
    -  ee0c0000-ee0c0fff : 0001:01:01.0
    -    ee0c0000-ee0c0fff : ohci_hcd
    -  ee0c1000-ee0c10ff : 0001:01:02.0
    -    ee0c1000-ee0c10ff : ehci_hcd
    +ee0c0000-ee0c0fff : ohci_hcd
    +ee0c1000-ee0c10ff : ehci_hcd
     ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
     ee100000-ee100327 : ee100000.mmc mmc@ee100000
     ee140000-ee1400ff : ee140000.mmc mmc@ee140000

I assume the others are gone because they now conflict with the *_hcd
resources at the top level.

> > > If this works, we'll also have to decide what to do with the BAR1 (it
> > > didn't appear in your (partial?) /proc/iomem quote so I'm left unsure how
> > > to approach it).
> >
> > That is indeed not visible in /proc/iomem.
>
> I meant before the commit 06b77d5647a4d6a7 ("PCI Mark resources
> IORESOURCE_UNSET when outside bridge windows"), was it present?

No, it was not present.

> > I tried the following (whitespace-damaged):
> >
> > --- a/drivers/pci/controller/pci-rcar-gen2.c
> > +++ b/drivers/pci/controller/pci-rcar-gen2.c
> > @@ -179,6 +179,7 @@ static void rcar_pci_setup(struct rcar_pci *priv)
> >         unsigned long window_size;
> >         unsigned long window_addr;
> >         unsigned long window_pci;
> > +       struct resource res;
> >         u32 val;
> >
> >         entry = resource_list_first_type(&bridge->dma_ranges, IORESOURCE_MEM);
> > @@ -191,6 +192,8 @@ static void rcar_pci_setup(struct rcar_pci *priv)
> >                 window_pci = entry->res->start - entry->offset;
> >                 window_size = resource_size(entry->res);
> >         }
> > +       resource_set_range(&res, window_addr, window_size);
>
> You need to set flags properly too as this now tried to insert BUS, not
> MEM resource (DEFINE_RES() might be the more appropriate in that case
> anyway).
>
> However, if there's not &bridge->dma_ranges ranges entry, rcar_pci_setup()
> seems to initialize the resource to 0x40000000-0x7fffffff and I'm not sure

I guess the not &bridge->dma_ranges case dates back to the time the
DTS didn't have dma-ranges yet.  However, upon closer look, the DTS
still doesn't have dma_ranges, thus always using the default.

> how it's supposed to work if there's more than one of these devices as per
> the log above.

Upon closer look, this is not a resource of the device, but an inbound
memory region.  Hence there is no issue if multiple devices use the
same region.

>
> > +       pci_add_resource(&bridge->windows, &res);
>
> What would be the backing resource in the resource tree for this? I'm not
> sure if pci_add_resource() is going to result in adding one into the
> resource tree.

Likewise, it should not appear in /proc/ioem.
Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 27054 bytes --]

On Mon, 6 Oct 2025, Geert Uytterhoeven wrote:
> On Fri, 3 Oct 2025 at 16:58, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Fri, 3 Oct 2025, Geert Uytterhoeven wrote:
> > > On Thu, 2 Oct 2025 at 18:59, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > On Thu, 2 Oct 2025, Geert Uytterhoeven wrote:
> > > > > On Thu, 2 Oct 2025 at 16:54, Ilpo Järvinen
> > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
> > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > > > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > > > > > > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > > > > > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > > > > > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > > > > > > > > with IORESOURCE_UNSET.
> > > > > > > > > > > >
> > > > > > > > > > > > Resources that do not reside within their bridge window, however, are
> > > > > > > > > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > > > > > > > > conflicts detected in quirk_system_pci_resources():
> > > > > > > > > > > >
> > > > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > > > > > > > > ...
> > > > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > > > > > > > > ...
> > > > > > > > > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > > > > > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > >
> > > > > > > > > > > > Mark resources that are not contained within their bridge window with
> > > > > > > > > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > > > > > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > > > > > > > > >
> > > > > > > > > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > > > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > > > > > > > >
> > > > > > > > > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > > > > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > > > > > > > > linux-next/master next-20250929 pci/next
> > > > > > > > >
> > > > > > > > > > > This replaces the actual resources by their sizes in the boot log on
> > > > > > > > > > > e.g. on R-Car M2-W:
> > > > > > > > > > >
> > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > > > > > > > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > > > > > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > > > > > > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > > > > > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > > > > > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > > > > > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > > > > > > > > >
> > > > > > > > > > What is going to be the parent of these resources? They don't seem to fall
> > > > > > > > > > under the root bus resource above in which case the output change is
> > > > > > > > > > intentional so they don't appear as if address range would be "okay".
> > > > > > > > >
> > > > > > > > > >From /proc/iomem:
> > > > > > > > >
> > > > > > > > >     ee080000-ee08ffff : pci@ee090000
> > > > > > > > >       ee080000-ee080fff : 0000:00:01.0
> > > > > > > > >         ee080000-ee080fff : ohci_hcd
> > > > > > > > >       ee081000-ee0810ff : 0000:00:02.0
> > > > > > > > >         ee081000-ee0810ff : ehci_hcd
> > > > > > > > >     ee090000-ee090bff : ee090000.pci pci@ee090000
> > > > > > > >
> > > > > > > > Okay, so this seem to appear in the resource tree but not among the root
> > > > > > > > bus resources.
> > > > > > > >
> > > > > > > > >     ee0c0000-ee0cffff : pci@ee0d0000
> > > > > > > > >       ee0c0000-ee0c0fff : 0001:01:01.0
> > > > > > > > >         ee0c0000-ee0c0fff : ohci_hcd
> > > > > > > > >       ee0c1000-ee0c10ff : 0001:01:02.0
> > > > > > > > >         ee0c1000-ee0c10ff : ehci_hcd
> > > > > > > > >
> > > > > > > > > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > > > > > > > > and end addresses.
> > > > > > > > >
> > > > > > > > > Yeah, that's how I found this commit, without bisecting ;-)
> > > > > > > > >
> > > > > > > > > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > > > > > > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > > > > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > > > > > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > > > > > > > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > > > > > > >
> > > > > > > > > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > > > > > > > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > > > > > > > > of the kernel to think that resource range valid and in use (in your
> > > > > > > > > > case it's so small it wouldn't collide with anything but it wasn't
> > > > > > > > > > properly set up resource, nonetheless).
> > > > > > > > > >
> > > > > > > > > > >      pci 0000:00:01.0: supports D1 D2
> > > > > > > > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > > > > > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > > > > > > > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > > > > > > >
> > > > > > > > > > And this as well is very much intentional.
> > > > > > > > > >
> > > > > > > > > > >      pci 0000:00:02.0: supports D1 D2
> > > > > > > > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > > > > > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > > > > > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > > > > > > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > > > > > > > >
> > > > > > > > > > > Is that intentional?
> > > > > > > > > >
> > > > > > > > > > There's also that pci_dbg() in the patch which would show the original
> > > > > > > > > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > > > > > > > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > > > > > > > > making that pci_info() though so it would appear always.
> > > > > > > > > >
> > > > > > > > > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > > > > > > > > getting assigned anywhere.
> > > > > > > > >
> > > > > > > > > The above log is almost complete (lacked enabling the device afterwards).
> > > > > > > > >
> > > > > > > > > AFAIU, the BARs come from the reg and ranges properties in the
> > > > > > > > > PCI controller nodes;
> > > > > > > > > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
> > > > > > > >
> > > > > > > > Thanks, although I had already found this line by grep. I was just
> > > > > > > > expecting the address appear among root bus resources too.
> > > > > > > >
> > > > > > > > Curiously enough, pci_register_host_bridge() seems to try to add some
> > > > > > > > resource from that list into bus and it's what prints those "root bus
> > > > > > > > resource" lines and ee090000 is not among the printed lines despite
> > > > > > > > appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> > > > > > > > resources seems to be in disagreement and I'm not sure what to make of it.
> > > > > > > >
> > > > > > > > But before considering going into that direction or figuring out why this
> > > > > > > > ee090000 resource does not appear among root bus resources, could you
> > > > > > > > check if the attached patch changes behavior for the resource which are
> > > > > > > > non-zero based?
> > > > > > >
> > > > > > > This patch has no impact on dmesg, lspci output, or /proc/iomem
> > > > > > > for pci-rcar-gen2.
> > > > > >
> > > > > > It would have been too easy... :-(
> > > > > >
> > > > > > I'm sorry I don't really know these platform well and I'm currently trying
> > > > > > to understand what adds that ee090000 resource into the resource tree
> > > > > > and so far I've not been very successful.
> > > > > >
> > > > > > Perhaps it would be easiest to print a stacktrace when the resource is
> > > > > > added but there are many possible functions. I think all of them
> > > > > > converge in __request_resource() so I suggest adding:
> > > > > >
> > > > > > WARN_ON(new->start == 0xee090000);
> > > > > >
> > > > > > before __request_resource() does anything.
> > > > >
> > > > >     Call trace:
> > > > >      unwind_backtrace from show_stack+0x10/0x14
> > > > >      show_stack from dump_stack_lvl+0x7c/0xb0
> > > > >      dump_stack_lvl from __warn+0x80/0x198
> > > > >      __warn from warn_slowpath_fmt+0xc0/0x124
> > > > >      warn_slowpath_fmt from __request_resource+0x38/0xc8
> > > > >      __request_resource from __request_region+0xc4/0x1e8
> > > > >      __request_region from __devm_request_region+0x80/0xac
> > > > >      __devm_request_region from __devm_ioremap_resource+0xcc/0x160
> > > > >      __devm_ioremap_resource from rcar_pci_probe+0x58/0x350
> > > > >      rcar_pci_probe from platform_probe+0x58/0x90
> > > > >
> > > > > I.e. the call to devm_platform_get_and_ioremap_resource() in
> > > > > drivers/pci/controller/pci-rcar-gen2.c:rcar_pci_probe().
> > > >
> > > > Thanks, the patch below might help BAR0 (but I'm not sure if it's the
> > > > correct solution due to being so unfamiliar with these kind of platforms
> > > > and how they're initialized).
> > >
> > > Thanks, that has the following impact on dmesg:
> > >
> > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > >      pci_bus 0000:00: root bus resource [bus 00]
> > >     -pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > >     +pci_bus 0000:00: root bus resource [mem 0xee080000-0xee090bff]
> > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
> > > PCI endpoint
> > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
> > > claim (no window)
> > >     -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> > > initial claim (no window)
> > >     +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > >      pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> > > PCI endpoint
> > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
> > > claim (no window)
> > >      pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > >      pci 0000:00:01.0: supports D1 D2
> > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
> > > PCI endpoint
> > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
> > > claim (no window)
> >
> > Did you e.g. forget to change pci_dbg() to pci_info() as these all went
> > away, I cannot see why it should disappear because of my patch?
> >
> > (No need to apologize if that was the case, just confirming if that
> > explains it is enough. :-))
> 
> I indeed dropped that change. Adding it back...
> 
> > >      pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > >      pci 0000:00:02.0: supports D1 D2
> > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > >      PCI: bus0: Fast back to back transfers disabled
> > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> >
> > Perhaps print here what's the parent resource of these resource.
> 
> pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned (parent
> [mem 0xee080000-0xee08ffff])
> pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned (parent
> [mem 0xee080000-0xee08ffff])

Were these from a kernel without the problematic commit at all or with the 
problematic commit and my fix? They look like the former case. The full 
/proc/iomem also shows all the parent resources I think.

> > >     -pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > >     +pci_bus 0000:00: resource 4 [mem 0xee080000-0xee090bff]
> > >      pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
> > >      PM: genpd_add_device: Add ee0d0000.pci to always-on
> > >      pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
> > >     @@ -414,26 +416,22 @@ PM: ==== always-on/ee0d0000.pci: start
> > >      pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
> > >      pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
> > >      pci_bus 0001:01: root bus resource [bus 01]
> > >     -pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
> > >     +pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0d0bff]
> > >      pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > >     -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial claim (no window)
> > >     -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
> > >     -pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no initial claim (no window)
> > >     +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
> > >      pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
> > >      pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > >     -pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial claim (no window)
> > >      pci 0001:01:01.0: BAR 0 [mem size 0x00001000]
> > >      pci 0001:01:01.0: supports D1 D2
> > >      pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
> > >      pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > >     -pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial claim (no window)
> > >      pci 0001:01:02.0: BAR 0 [mem size 0x00000100]
> > >      pci 0001:01:02.0: supports D1 D2
> > >      pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
> > >      PCI: bus1: Fast back to back transfers disabled
> > >      pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
> > >      pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
> > >     -pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
> > >     +pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0d0bff]
> > >      rcar-pcie fe000000.pcie: adding to PM domain always-on
> > >      PM: genpd_add_device: Add fe000000.pcie to always-on
> > >      rcar-pcie fe000000.pcie: host bridge /soc/pcie@fe000000 ranges:
> > >
> > > and on /proc/iomem (I used "diff -w" to reduce clutter):
> > >
> > >      ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
> > >      ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
> > >      ec740000-ec7401ff : ec500000.sound audmapp
> > >     -ee080000-ee08ffff : pci@ee090000
> >
> > So what did add this previous? (Maybe use the same WARN_ON() trick as
> > previously to find out.)
> 
> First call:
> 
>     + __request_resource from request_resource_conflict+0x24/0x3c
>     + request_resource_conflict from devm_request_resource+0x48/0x9c
>     + devm_request_resource from devm_request_pci_bus_resources+0x5c/0x70
>     + devm_request_pci_bus_resources from devm_of_pci_bridge_init+0x7c/0x1c0
>     + devm_of_pci_bridge_init from devm_pci_alloc_host_bridge+0x44/0x6c
>     + devm_pci_alloc_host_bridge from rcar_pci_probe+0x34/0x384
>     + rcar_pci_probe from platform_probe+0x58/0x90

Thanks. So this is the call of interest, the rest are just the childs of 
it with the same address.

I'm looking devm_of_pci_get_host_bridge_resources(), it seems to read 
"ranges" property but not "reg" at all.

I wonder if devm_of_pci_get_host_bridge_resources() should also loop 
through "reg" addresses and add those to host resources which are outside 
of the "ranges"? Or if there should be a "range" that covers all what's 
in "reg" to get them added into host bridge resources? That would seem the 
generic solution instead of trying to do this in rcar_pci_probe().

(Perhaps these are stupid questions, please excuse my lack of knowledge 
about OF things.)


While looking at another issue report, I also notice of_pci_prop_ranges() 
assumes there are only bridge windows or BARs, but not both (not sure if 
this relates to anything, just an observation while reading these code 
paths).


> Second call:
> 
>     + __request_resource from allocate_resource+0x1b8/0x1d4
>     + allocate_resource from pci_bus_alloc_from_region+0x1e0/0x220
>     + pci_bus_alloc_from_region from pci_bus_alloc_resource+0x84/0xb8
>     + pci_bus_alloc_resource from _pci_assign_resource+0x78/0x150
>     + _pci_assign_resource from pci_assign_resource+0x10c/0x310
>     + pci_assign_resource from assign_requested_resources_sorted+0x78/0xac
>     + assign_requested_resources_sorted from
> __assign_resources_sorted+0x74/0x5c4
>     + __assign_resources_sorted from __pci_bus_assign_resources+0x50/0x1f0
>     + __pci_bus_assign_resources from
> pci_assign_unassigned_root_bus_resources+0xa8/0x190
>     + pci_assign_unassigned_root_bus_resources from pci_host_probe+0x5c/0xb0
>     + pci_host_probe from rcar_pci_probe+0x2e0/0x384
>     + rcar_pci_probe from platform_probe+0x58/0x90
> 
> Third call:
> 
>     + __request_resource from __request_region+0xc4/0x1e8
>     + __request_region from __devm_request_region+0x80/0xac
>     + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
>     + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
>     + pci_device_probe from really_probe+0x128/0x28c
> 
> Fourth call:
> 
>     + __request_region from __devm_request_region+0x80/0xac
>     + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
>     + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
>     + pci_device_probe from really_probe+0x128/0x28c
> 
> Fifth call:
> 
>     + __request_region from __devm_request_region+0x80/0xac
>     + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
>     + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
>     + pci_device_probe from really_probe+0x128/0x28c
> 
> > It might have gotten broken because the coalesed resource
> > ee080000-ee090bff overlaps with that other resource in the resource tree.
> > But I don't see anything to that effect in the log so it's either silent
> > failure or there's much filtered from the log.
> >
> > >     -  ee080000-ee080fff : 0000:00:01.0
> > >          ee080000-ee080fff : ohci_hcd
> > >     -  ee081000-ee0810ff : 0000:00:02.0
> > >          ee081000-ee0810ff : ehci_hcd
> > >      ee090000-ee090bff : ee090000.pci pci@ee090000
> > >     -ee0c0000-ee0cffff : pci@ee0d0000
> > >     -  ee0c0000-ee0c0fff : 0001:01:01.0
> > >          ee0c0000-ee0c0fff : ohci_hcd
> > >     -  ee0c1000-ee0c10ff : 0001:01:02.0
> > >          ee0c1000-ee0c10ff : ehci_hcd
> > >      ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
> > >      ee100000-ee100327 : ee100000.mmc mmc@ee100000
> > >
> > > Removing the pci@ee0x0000 and 000x:0x:0x.0 entries doesn't look
> > > right to me? Or am I missing something?
> >
> > I cannot understand this output, these resources seem to have been now
> > left without a parent and due to -w I don't know what's their real
> > indentation level.
> 
> The *_hcd resources are now at the top level.
> 
>      ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
>      ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
>      ec740000-ec7401ff : ec500000.sound audmapp
>     -ee080000-ee08ffff : pci@ee090000
>     -  ee080000-ee080fff : 0000:00:01.0
>     -    ee080000-ee080fff : ohci_hcd
>     -  ee081000-ee0810ff : 0000:00:02.0
>     -    ee081000-ee0810ff : ehci_hcd
>     +ee080000-ee080fff : ohci_hcd
>     +ee081000-ee0810ff : ehci_hcd
>      ee090000-ee090bff : ee090000.pci pci@ee090000
>     -ee0c0000-ee0cffff : pci@ee0d0000
>     -  ee0c0000-ee0c0fff : 0001:01:01.0
>     -    ee0c0000-ee0c0fff : ohci_hcd
>     -  ee0c1000-ee0c10ff : 0001:01:02.0
>     -    ee0c1000-ee0c10ff : ehci_hcd
>     +ee0c0000-ee0c0fff : ohci_hcd
>     +ee0c1000-ee0c10ff : ehci_hcd
>      ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
>      ee100000-ee100327 : ee100000.mmc mmc@ee100000
>      ee140000-ee1400ff : ee140000.mmc mmc@ee140000
> 
> I assume the others are gone because they now conflict with the *_hcd
> resources at the top level.

Like you initially assumed, it is wrong (while it works as the resources 
themselves don't care that much about their parent they're under as long 
as the resource is assigned, it's still not intended to be that way).

It might be worth to see if the coalescing in pci_register_host_bridge() 
somehow messes these resources up either by not doing the coalesing loop 
at all or by adding:

		if (res->parent || next_res->parent) {
			if (res->parent)
				pr_info("Has parent %pR\n", res);
			if (next_res->parent)
				pr_info("Has parent %pR\n", next_res);
			continue;
		}

...into the coalescing loop in case one of them happens to have a parent
(this is to be tested with the rcar_probe() fix).

> > > > If this works, we'll also have to decide what to do with the BAR1 (it
> > > > didn't appear in your (partial?) /proc/iomem quote so I'm left unsure how
> > > > to approach it).
> > >
> > > That is indeed not visible in /proc/iomem.
> >
> > I meant before the commit 06b77d5647a4d6a7 ("PCI Mark resources
> > IORESOURCE_UNSET when outside bridge windows"), was it present?
> 
> No, it was not present.
> 
> > > I tried the following (whitespace-damaged):
> > >
> > > --- a/drivers/pci/controller/pci-rcar-gen2.c
> > > +++ b/drivers/pci/controller/pci-rcar-gen2.c
> > > @@ -179,6 +179,7 @@ static void rcar_pci_setup(struct rcar_pci *priv)
> > >         unsigned long window_size;
> > >         unsigned long window_addr;
> > >         unsigned long window_pci;
> > > +       struct resource res;
> > >         u32 val;
> > >
> > >         entry = resource_list_first_type(&bridge->dma_ranges, IORESOURCE_MEM);
> > > @@ -191,6 +192,8 @@ static void rcar_pci_setup(struct rcar_pci *priv)
> > >                 window_pci = entry->res->start - entry->offset;
> > >                 window_size = resource_size(entry->res);
> > >         }
> > > +       resource_set_range(&res, window_addr, window_size);
> >
> > You need to set flags properly too as this now tried to insert BUS, not
> > MEM resource (DEFINE_RES() might be the more appropriate in that case
> > anyway).
> >
> > However, if there's not &bridge->dma_ranges ranges entry, rcar_pci_setup()
> > seems to initialize the resource to 0x40000000-0x7fffffff and I'm not sure
> 
> I guess the not &bridge->dma_ranges case dates back to the time the
> DTS didn't have dma-ranges yet.  However, upon closer look, the DTS
> still doesn't have dma_ranges, thus always using the default.
> 
> > how it's supposed to work if there's more than one of these devices as per
> > the log above.
> 
> Upon closer look, this is not a resource of the device, but an inbound
> memory region.  Hence there is no issue if multiple devices use the
> same region.
> 
> >
> > > +       pci_add_resource(&bridge->windows, &res);
> >
> > What would be the backing resource in the resource tree for this? I'm not
> > sure if pci_add_resource() is going to result in adding one into the
> > resource tree.
> 
> Likewise, it should not appear in /proc/ioem.

Thanks for checking it out.

I wonder how it would be supposed to work if PCI resource fitting logic 
finds place for it and changes its address. I don't think it would ever 
happen because it should never fit...

...But the logic still is a bit fishy if rcar2 code expects that address 
to be fixed but doesn't flag the resource to have a fixed address.

-- 
 i.

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Geert Uytterhoeven]

Hi Ilpo,

On Mon, 6 Oct 2025 at 14:37, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> On Mon, 6 Oct 2025, Geert Uytterhoeven wrote:
> > On Fri, 3 Oct 2025 at 16:58, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > On Fri, 3 Oct 2025, Geert Uytterhoeven wrote:
> > > > On Thu, 2 Oct 2025 at 18:59, Ilpo Järvinen
> > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > On Thu, 2 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > On Thu, 2 Oct 2025 at 16:54, Ilpo Järvinen
> > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > > On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
> > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > > > > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > > > > > > > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > > > > > > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > > > > > > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > > > > > > > > > with IORESOURCE_UNSET.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Resources that do not reside within their bridge window, however, are
> > > > > > > > > > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > > > > > > > > > conflicts detected in quirk_system_pci_resources():
> > > > > > > > > > > > >
> > > > > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > > > > > > > > > ...
> > > > > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > > > > > > > > > ...
> > > > > > > > > > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > >
> > > > > > > > > > > > > Mark resources that are not contained within their bridge window with
> > > > > > > > > > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > > > > > > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > > > > > > > > > >
> > > > > > > > > > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > > > > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > > > > > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > > > > > > > > > linux-next/master next-20250929 pci/next
> > > > > > > > > >
> > > > > > > > > > > > This replaces the actual resources by their sizes in the boot log on
> > > > > > > > > > > > e.g. on R-Car M2-W:
> > > > > > > > > > > >
> > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > > > > > > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > > > > > > > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > > > > > > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > > > > > > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > > > > > > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > > > > > > > > > >
> > > > > > > > > > > What is going to be the parent of these resources? They don't seem to fall
> > > > > > > > > > > under the root bus resource above in which case the output change is
> > > > > > > > > > > intentional so they don't appear as if address range would be "okay".
> > > > > > > > > >
> > > > > > > > > > >From /proc/iomem:
> > > > > > > > > >
> > > > > > > > > >     ee080000-ee08ffff : pci@ee090000
> > > > > > > > > >       ee080000-ee080fff : 0000:00:01.0
> > > > > > > > > >         ee080000-ee080fff : ohci_hcd
> > > > > > > > > >       ee081000-ee0810ff : 0000:00:02.0
> > > > > > > > > >         ee081000-ee0810ff : ehci_hcd
> > > > > > > > > >     ee090000-ee090bff : ee090000.pci pci@ee090000
> > > > > > > > >
> > > > > > > > > Okay, so this seem to appear in the resource tree but not among the root
> > > > > > > > > bus resources.
> > > > > > > > >
> > > > > > > > > >     ee0c0000-ee0cffff : pci@ee0d0000
> > > > > > > > > >       ee0c0000-ee0c0fff : 0001:01:01.0
> > > > > > > > > >         ee0c0000-ee0c0fff : ohci_hcd
> > > > > > > > > >       ee0c1000-ee0c10ff : 0001:01:02.0
> > > > > > > > > >         ee0c1000-ee0c10ff : ehci_hcd
> > > > > > > > > >
> > > > > > > > > > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > > > > > > > > > and end addresses.
> > > > > > > > > >
> > > > > > > > > > Yeah, that's how I found this commit, without bisecting ;-)
> > > > > > > > > >
> > > > > > > > > > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > > > > > > > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > > > > > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > > > > > > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > > > > > > > > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > > > > > > > >
> > > > > > > > > > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > > > > > > > > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > > > > > > > > > of the kernel to think that resource range valid and in use (in your
> > > > > > > > > > > case it's so small it wouldn't collide with anything but it wasn't
> > > > > > > > > > > properly set up resource, nonetheless).
> > > > > > > > > > >
> > > > > > > > > > > >      pci 0000:00:01.0: supports D1 D2
> > > > > > > > > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > > > > > > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > > > > > > > > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > > > > > > > >
> > > > > > > > > > > And this as well is very much intentional.
> > > > > > > > > > >
> > > > > > > > > > > >      pci 0000:00:02.0: supports D1 D2
> > > > > > > > > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > > > > > > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > > > > > > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > > > > > > > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > > > > > > > > >
> > > > > > > > > > > > Is that intentional?
> > > > > > > > > > >
> > > > > > > > > > > There's also that pci_dbg() in the patch which would show the original
> > > > > > > > > > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > > > > > > > > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > > > > > > > > > making that pci_info() though so it would appear always.
> > > > > > > > > > >
> > > > > > > > > > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > > > > > > > > > getting assigned anywhere.
> > > > > > > > > >
> > > > > > > > > > The above log is almost complete (lacked enabling the device afterwards).
> > > > > > > > > >
> > > > > > > > > > AFAIU, the BARs come from the reg and ranges properties in the
> > > > > > > > > > PCI controller nodes;
> > > > > > > > > > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
> > > > > > > > >
> > > > > > > > > Thanks, although I had already found this line by grep. I was just
> > > > > > > > > expecting the address appear among root bus resources too.
> > > > > > > > >
> > > > > > > > > Curiously enough, pci_register_host_bridge() seems to try to add some
> > > > > > > > > resource from that list into bus and it's what prints those "root bus
> > > > > > > > > resource" lines and ee090000 is not among the printed lines despite
> > > > > > > > > appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> > > > > > > > > resources seems to be in disagreement and I'm not sure what to make of it.
> > > > > > > > >
> > > > > > > > > But before considering going into that direction or figuring out why this
> > > > > > > > > ee090000 resource does not appear among root bus resources, could you
> > > > > > > > > check if the attached patch changes behavior for the resource which are
> > > > > > > > > non-zero based?
> > > > > > > >
> > > > > > > > This patch has no impact on dmesg, lspci output, or /proc/iomem
> > > > > > > > for pci-rcar-gen2.
> > > > > > >
> > > > > > > It would have been too easy... :-(
> > > > > > >
> > > > > > > I'm sorry I don't really know these platform well and I'm currently trying
> > > > > > > to understand what adds that ee090000 resource into the resource tree
> > > > > > > and so far I've not been very successful.
> > > > > > >
> > > > > > > Perhaps it would be easiest to print a stacktrace when the resource is
> > > > > > > added but there are many possible functions. I think all of them
> > > > > > > converge in __request_resource() so I suggest adding:
> > > > > > >
> > > > > > > WARN_ON(new->start == 0xee090000);
> > > > > > >
> > > > > > > before __request_resource() does anything.
> > > > > >
> > > > > >     Call trace:
> > > > > >      unwind_backtrace from show_stack+0x10/0x14
> > > > > >      show_stack from dump_stack_lvl+0x7c/0xb0
> > > > > >      dump_stack_lvl from __warn+0x80/0x198
> > > > > >      __warn from warn_slowpath_fmt+0xc0/0x124
> > > > > >      warn_slowpath_fmt from __request_resource+0x38/0xc8
> > > > > >      __request_resource from __request_region+0xc4/0x1e8
> > > > > >      __request_region from __devm_request_region+0x80/0xac
> > > > > >      __devm_request_region from __devm_ioremap_resource+0xcc/0x160
> > > > > >      __devm_ioremap_resource from rcar_pci_probe+0x58/0x350
> > > > > >      rcar_pci_probe from platform_probe+0x58/0x90
> > > > > >
> > > > > > I.e. the call to devm_platform_get_and_ioremap_resource() in
> > > > > > drivers/pci/controller/pci-rcar-gen2.c:rcar_pci_probe().
> > > > >
> > > > > Thanks, the patch below might help BAR0 (but I'm not sure if it's the
> > > > > correct solution due to being so unfamiliar with these kind of platforms
> > > > > and how they're initialized).
> > > >
> > > > Thanks, that has the following impact on dmesg:
> > > >
> > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > >     -pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > >     +pci_bus 0000:00: root bus resource [mem 0xee080000-0xee090bff]
> > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
> > > > PCI endpoint
> > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
> > > > claim (no window)
> > > >     -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> > > > initial claim (no window)
> > > >     +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > >      pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> > > > PCI endpoint
> > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
> > > > claim (no window)
> > > >      pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > >      pci 0000:00:01.0: supports D1 D2
> > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
> > > > PCI endpoint
> > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
> > > > claim (no window)
> > >
> > > Did you e.g. forget to change pci_dbg() to pci_info() as these all went
> > > away, I cannot see why it should disappear because of my patch?
> > >
> > > (No need to apologize if that was the case, just confirming if that
> > > explains it is enough. :-))
> >
> > I indeed dropped that change. Adding it back...
> >
> > > >      pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > >      pci 0000:00:02.0: supports D1 D2
> > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > >      PCI: bus0: Fast back to back transfers disabled
> > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > >
> > > Perhaps print here what's the parent resource of these resource.
> >
> > pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned (parent
> > [mem 0xee080000-0xee08ffff])
> > pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned (parent
> > [mem 0xee080000-0xee08ffff])
>
> Were these from a kernel without the problematic commit at all or with the
> problematic commit and my fix? They look like the former case. The full
> /proc/iomem also shows all the parent resources I think.

With commit 06b77d5647a4d6a7 ("PCI: Mark resources IORESOURCE_UNSET when
outside bridge windows"), but without adding
"pci_add_resource(&bridge->windows, cfg_res);" in .probe().

> > > >     -pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > >     +pci_bus 0000:00: resource 4 [mem 0xee080000-0xee090bff]
> > > >      pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
> > > >      PM: genpd_add_device: Add ee0d0000.pci to always-on
> > > >      pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
> > > >     @@ -414,26 +416,22 @@ PM: ==== always-on/ee0d0000.pci: start
> > > >      pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
> > > >      pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
> > > >      pci_bus 0001:01: root bus resource [bus 01]
> > > >     -pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
> > > >     +pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0d0bff]
> > > >      pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > >     -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial claim (no window)
> > > >     -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
> > > >     -pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no initial claim (no window)
> > > >     +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
> > > >      pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
> > > >      pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > >     -pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial claim (no window)
> > > >      pci 0001:01:01.0: BAR 0 [mem size 0x00001000]
> > > >      pci 0001:01:01.0: supports D1 D2
> > > >      pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
> > > >      pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > >     -pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial claim (no window)
> > > >      pci 0001:01:02.0: BAR 0 [mem size 0x00000100]
> > > >      pci 0001:01:02.0: supports D1 D2
> > > >      pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
> > > >      PCI: bus1: Fast back to back transfers disabled
> > > >      pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
> > > >      pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
> > > >     -pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
> > > >     +pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0d0bff]
> > > >      rcar-pcie fe000000.pcie: adding to PM domain always-on
> > > >      PM: genpd_add_device: Add fe000000.pcie to always-on
> > > >      rcar-pcie fe000000.pcie: host bridge /soc/pcie@fe000000 ranges:
> > > >
> > > > and on /proc/iomem (I used "diff -w" to reduce clutter):
> > > >
> > > >      ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
> > > >      ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
> > > >      ec740000-ec7401ff : ec500000.sound audmapp
> > > >     -ee080000-ee08ffff : pci@ee090000
> > >
> > > So what did add this previous? (Maybe use the same WARN_ON() trick as
> > > previously to find out.)
> >
> > First call:
> >
> >     + __request_resource from request_resource_conflict+0x24/0x3c
> >     + request_resource_conflict from devm_request_resource+0x48/0x9c
> >     + devm_request_resource from devm_request_pci_bus_resources+0x5c/0x70
> >     + devm_request_pci_bus_resources from devm_of_pci_bridge_init+0x7c/0x1c0
> >     + devm_of_pci_bridge_init from devm_pci_alloc_host_bridge+0x44/0x6c
> >     + devm_pci_alloc_host_bridge from rcar_pci_probe+0x34/0x384
> >     + rcar_pci_probe from platform_probe+0x58/0x90
>
> Thanks. So this is the call of interest, the rest are just the childs of
> it with the same address.
>
> I'm looking devm_of_pci_get_host_bridge_resources(), it seems to read
> "ranges" property but not "reg" at all.
>
> I wonder if devm_of_pci_get_host_bridge_resources() should also loop
> through "reg" addresses and add those to host resources which are outside
> of the "ranges"? Or if there should be a "range" that covers all what's
> in "reg" to get them added into host bridge resources? That would seem the
> generic solution instead of trying to do this in rcar_pci_probe().
>
> (Perhaps these are stupid questions, please excuse my lack of knowledge
> about OF things.)
>
> While looking at another issue report, I also notice of_pci_prop_ranges()
> assumes there are only bridge windows or BARs, but not both (not sure if
> this relates to anything, just an observation while reading these code
> paths).

We still have Rob in CC...

> > Second call:
> >
> >     + __request_resource from allocate_resource+0x1b8/0x1d4
> >     + allocate_resource from pci_bus_alloc_from_region+0x1e0/0x220
> >     + pci_bus_alloc_from_region from pci_bus_alloc_resource+0x84/0xb8
> >     + pci_bus_alloc_resource from _pci_assign_resource+0x78/0x150
> >     + _pci_assign_resource from pci_assign_resource+0x10c/0x310
> >     + pci_assign_resource from assign_requested_resources_sorted+0x78/0xac
> >     + assign_requested_resources_sorted from
> > __assign_resources_sorted+0x74/0x5c4
> >     + __assign_resources_sorted from __pci_bus_assign_resources+0x50/0x1f0
> >     + __pci_bus_assign_resources from
> > pci_assign_unassigned_root_bus_resources+0xa8/0x190
> >     + pci_assign_unassigned_root_bus_resources from pci_host_probe+0x5c/0xb0
> >     + pci_host_probe from rcar_pci_probe+0x2e0/0x384
> >     + rcar_pci_probe from platform_probe+0x58/0x90
> >
> > Third call:
> >
> >     + __request_resource from __request_region+0xc4/0x1e8
> >     + __request_region from __devm_request_region+0x80/0xac
> >     + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
> >     + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
> >     + pci_device_probe from really_probe+0x128/0x28c
> >
> > Fourth call:
> >
> >     + __request_region from __devm_request_region+0x80/0xac
> >     + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
> >     + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
> >     + pci_device_probe from really_probe+0x128/0x28c
> >
> > Fifth call:
> >
> >     + __request_region from __devm_request_region+0x80/0xac
> >     + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
> >     + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
> >     + pci_device_probe from really_probe+0x128/0x28c
> >
> > > It might have gotten broken because the coalesed resource
> > > ee080000-ee090bff overlaps with that other resource in the resource tree.
> > > But I don't see anything to that effect in the log so it's either silent
> > > failure or there's much filtered from the log.
> > >
> > > >     -  ee080000-ee080fff : 0000:00:01.0
> > > >          ee080000-ee080fff : ohci_hcd
> > > >     -  ee081000-ee0810ff : 0000:00:02.0
> > > >          ee081000-ee0810ff : ehci_hcd
> > > >      ee090000-ee090bff : ee090000.pci pci@ee090000
> > > >     -ee0c0000-ee0cffff : pci@ee0d0000
> > > >     -  ee0c0000-ee0c0fff : 0001:01:01.0
> > > >          ee0c0000-ee0c0fff : ohci_hcd
> > > >     -  ee0c1000-ee0c10ff : 0001:01:02.0
> > > >          ee0c1000-ee0c10ff : ehci_hcd
> > > >      ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
> > > >      ee100000-ee100327 : ee100000.mmc mmc@ee100000
> > > >
> > > > Removing the pci@ee0x0000 and 000x:0x:0x.0 entries doesn't look
> > > > right to me? Or am I missing something?
> > >
> > > I cannot understand this output, these resources seem to have been now
> > > left without a parent and due to -w I don't know what's their real
> > > indentation level.
> >
> > The *_hcd resources are now at the top level.
> >
> >      ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
> >      ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
> >      ec740000-ec7401ff : ec500000.sound audmapp
> >     -ee080000-ee08ffff : pci@ee090000
> >     -  ee080000-ee080fff : 0000:00:01.0
> >     -    ee080000-ee080fff : ohci_hcd
> >     -  ee081000-ee0810ff : 0000:00:02.0
> >     -    ee081000-ee0810ff : ehci_hcd
> >     +ee080000-ee080fff : ohci_hcd
> >     +ee081000-ee0810ff : ehci_hcd
> >      ee090000-ee090bff : ee090000.pci pci@ee090000
> >     -ee0c0000-ee0cffff : pci@ee0d0000
> >     -  ee0c0000-ee0c0fff : 0001:01:01.0
> >     -    ee0c0000-ee0c0fff : ohci_hcd
> >     -  ee0c1000-ee0c10ff : 0001:01:02.0
> >     -    ee0c1000-ee0c10ff : ehci_hcd
> >     +ee0c0000-ee0c0fff : ohci_hcd
> >     +ee0c1000-ee0c10ff : ehci_hcd
> >      ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
> >      ee100000-ee100327 : ee100000.mmc mmc@ee100000
> >      ee140000-ee1400ff : ee140000.mmc mmc@ee140000
> >
> > I assume the others are gone because they now conflict with the *_hcd
> > resources at the top level.
>
> Like you initially assumed, it is wrong (while it works as the resources
> themselves don't care that much about their parent they're under as long
> as the resource is assigned, it's still not intended to be that way).
>
> It might be worth to see if the coalescing in pci_register_host_bridge()
> somehow messes these resources up either by not doing the coalesing loop
> at all or by adding:
>
>                 if (res->parent || next_res->parent) {
>                         if (res->parent)
>                                 pr_info("Has parent %pR\n", res);
>                         if (next_res->parent)
>                                 pr_info("Has parent %pR\n", next_res);
>                         continue;
>                 }
>
> ...into the coalescing loop in case one of them happens to have a parent
> (this is to be tested with the rcar_probe() fix).

The above restores the missing entries in /proc/iomem.
Changes to dmesg:

     pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
     pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff
-> 0x00ee080000
     pci-rcar-gen2 ee090000.pci: PCI: revision 11
     pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
    +Has parent [mem 0xee080000-0xee08ffff]
     pci_bus 0000:00: root bus resource [bus 00]
     pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
    +pci_bus 0000:00: root bus resource [mem 0xee090000-0xee090bff]
     pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
PCI endpoint
    -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
claim (no window)
    -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
    +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
     pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
initial claim (no window)
     pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
     pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
PCI endpoint
    @@ -403,21 +397,24 @@ pci 0000:00:02.0: BAR 0 [mem size 0x0000
     pci 0000:00:02.0: supports D1 D2
     pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
     PCI: bus0: Fast back to back transfers disabled
     pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
     pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
     pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
    +pci_bus 0000:00: resource 5 [mem 0xee090000-0xee090bff]
     pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
     pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
     pci-rcar-gen2 ee0d0000.pci:      MEM 0x00ee0c0000..0x00ee0cffff
-> 0x00ee0c0000
     pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
     pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
    +Has parent [mem 0xee0c0000-0xee0cffff]
     pci_bus 0001:01: root bus resource [bus 01]
     pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
    +pci_bus 0001:01: root bus resource [mem 0xee0d0000-0xee0d0bff]
     pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional
PCI endpoint
    -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial
claim (no window)
    -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
    +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
     pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
initial claim (no window)
     pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
     pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional
PCI endpoint
    @@ -431,9 +428,10 @@ pci 0001:01:02.0: BAR 0 [mem size 0x0000
     pci 0001:01:02.0: supports D1 D2
     pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
     PCI: bus1: Fast back to back transfers disabled
     pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
     pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
     pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
    +pci_bus 0001:01: resource 5 [mem 0xee0d0000-0xee0d0bff]

> > > > > If this works, we'll also have to decide what to do with the BAR1 (it
> > > > > didn't appear in your (partial?) /proc/iomem quote so I'm left unsure how
> > > > > to approach it).
> > > >
> > > > That is indeed not visible in /proc/iomem.
> > >
> > > I meant before the commit 06b77d5647a4d6a7 ("PCI Mark resources
> > > IORESOURCE_UNSET when outside bridge windows"), was it present?
> >
> > No, it was not present.
> >
> > > > I tried the following (whitespace-damaged):
> > > >
> > > > --- a/drivers/pci/controller/pci-rcar-gen2.c
> > > > +++ b/drivers/pci/controller/pci-rcar-gen2.c
> > > > @@ -179,6 +179,7 @@ static void rcar_pci_setup(struct rcar_pci *priv)
> > > >         unsigned long window_size;
> > > >         unsigned long window_addr;
> > > >         unsigned long window_pci;
> > > > +       struct resource res;
> > > >         u32 val;
> > > >
> > > >         entry = resource_list_first_type(&bridge->dma_ranges, IORESOURCE_MEM);
> > > > @@ -191,6 +192,8 @@ static void rcar_pci_setup(struct rcar_pci *priv)
> > > >                 window_pci = entry->res->start - entry->offset;
> > > >                 window_size = resource_size(entry->res);
> > > >         }
> > > > +       resource_set_range(&res, window_addr, window_size);
> > >
> > > You need to set flags properly too as this now tried to insert BUS, not
> > > MEM resource (DEFINE_RES() might be the more appropriate in that case
> > > anyway).
> > >
> > > However, if there's not &bridge->dma_ranges ranges entry, rcar_pci_setup()
> > > seems to initialize the resource to 0x40000000-0x7fffffff and I'm not sure
> >
> > I guess the not &bridge->dma_ranges case dates back to the time the
> > DTS didn't have dma-ranges yet.  However, upon closer look, the DTS
> > still doesn't have dma_ranges, thus always using the default.
> >
> > > how it's supposed to work if there's more than one of these devices as per
> > > the log above.
> >
> > Upon closer look, this is not a resource of the device, but an inbound
> > memory region.  Hence there is no issue if multiple devices use the
> > same region.
> >
> > >
> > > > +       pci_add_resource(&bridge->windows, &res);
> > >
> > > What would be the backing resource in the resource tree for this? I'm not
> > > sure if pci_add_resource() is going to result in adding one into the
> > > resource tree.
> >
> > Likewise, it should not appear in /proc/ioem.
>
> Thanks for checking it out.
>
> I wonder how it would be supposed to work if PCI resource fitting logic
> finds place for it and changes its address. I don't think it would ever
> happen because it should never fit...
>
> ...But the logic still is a bit fishy if rcar2 code expects that address
> to be fixed but doesn't flag the resource to have a fixed address.

How can the PCI resource fitting logic change it? It is an inbound
memory region, not a normal BAR?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 34051 bytes --]

+ Kai-Heng

On Mon, 6 Oct 2025, Geert Uytterhoeven wrote:
> On Mon, 6 Oct 2025 at 14:37, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Mon, 6 Oct 2025, Geert Uytterhoeven wrote:
> > > On Fri, 3 Oct 2025 at 16:58, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > On Fri, 3 Oct 2025, Geert Uytterhoeven wrote:
> > > > > On Thu, 2 Oct 2025 at 18:59, Ilpo Järvinen
> > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > On Thu, 2 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > On Thu, 2 Oct 2025 at 16:54, Ilpo Järvinen
> > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > > > On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
> > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > > > > > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > > > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > > > > > > > > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > > > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > > > > > > > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > > > > > > > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > > > > > > > > > > with IORESOURCE_UNSET.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Resources that do not reside within their bridge window, however, are
> > > > > > > > > > > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > > > > > > > > > > conflicts detected in quirk_system_pci_resources():
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Mark resources that are not contained within their bridge window with
> > > > > > > > > > > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > > > > > > > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > > > > > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > > > > > > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > > > > > > > > > > linux-next/master next-20250929 pci/next
> > > > > > > > > > >
> > > > > > > > > > > > > This replaces the actual resources by their sizes in the boot log on
> > > > > > > > > > > > > e.g. on R-Car M2-W:
> > > > > > > > > > > > >
> > > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > > > > > > > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > > > > > > > > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > > > > > > > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > > > > > > > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > > > > > > > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > > > > > > > > > > >
> > > > > > > > > > > > What is going to be the parent of these resources? They don't seem to fall
> > > > > > > > > > > > under the root bus resource above in which case the output change is
> > > > > > > > > > > > intentional so they don't appear as if address range would be "okay".
> > > > > > > > > > >
> > > > > > > > > > > >From /proc/iomem:
> > > > > > > > > > >
> > > > > > > > > > >     ee080000-ee08ffff : pci@ee090000
> > > > > > > > > > >       ee080000-ee080fff : 0000:00:01.0
> > > > > > > > > > >         ee080000-ee080fff : ohci_hcd
> > > > > > > > > > >       ee081000-ee0810ff : 0000:00:02.0
> > > > > > > > > > >         ee081000-ee0810ff : ehci_hcd
> > > > > > > > > > >     ee090000-ee090bff : ee090000.pci pci@ee090000
> > > > > > > > > >
> > > > > > > > > > Okay, so this seem to appear in the resource tree but not among the root
> > > > > > > > > > bus resources.
> > > > > > > > > >
> > > > > > > > > > >     ee0c0000-ee0cffff : pci@ee0d0000
> > > > > > > > > > >       ee0c0000-ee0c0fff : 0001:01:01.0
> > > > > > > > > > >         ee0c0000-ee0c0fff : ohci_hcd
> > > > > > > > > > >       ee0c1000-ee0c10ff : 0001:01:02.0
> > > > > > > > > > >         ee0c1000-ee0c10ff : ehci_hcd
> > > > > > > > > > >
> > > > > > > > > > > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > > > > > > > > > > and end addresses.
> > > > > > > > > > >
> > > > > > > > > > > Yeah, that's how I found this commit, without bisecting ;-)
> > > > > > > > > > >
> > > > > > > > > > > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > > > > > > > > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > > > > > > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > > > > > > > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > > > > > > > > > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > > > > > > > > >
> > > > > > > > > > > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > > > > > > > > > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > > > > > > > > > > of the kernel to think that resource range valid and in use (in your
> > > > > > > > > > > > case it's so small it wouldn't collide with anything but it wasn't
> > > > > > > > > > > > properly set up resource, nonetheless).
> > > > > > > > > > > >
> > > > > > > > > > > > >      pci 0000:00:01.0: supports D1 D2
> > > > > > > > > > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > > > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > > > > > > > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > > > > > > > > > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > > > > > > > > >
> > > > > > > > > > > > And this as well is very much intentional.
> > > > > > > > > > > >
> > > > > > > > > > > > >      pci 0000:00:02.0: supports D1 D2
> > > > > > > > > > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > > > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > > > > > > > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > > > > > > > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > > > > > > > > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > > > > > > > > > >
> > > > > > > > > > > > > Is that intentional?
> > > > > > > > > > > >
> > > > > > > > > > > > There's also that pci_dbg() in the patch which would show the original
> > > > > > > > > > > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > > > > > > > > > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > > > > > > > > > > making that pci_info() though so it would appear always.
> > > > > > > > > > > >
> > > > > > > > > > > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > > > > > > > > > > getting assigned anywhere.
> > > > > > > > > > >
> > > > > > > > > > > The above log is almost complete (lacked enabling the device afterwards).
> > > > > > > > > > >
> > > > > > > > > > > AFAIU, the BARs come from the reg and ranges properties in the
> > > > > > > > > > > PCI controller nodes;
> > > > > > > > > > > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
> > > > > > > > > >
> > > > > > > > > > Thanks, although I had already found this line by grep. I was just
> > > > > > > > > > expecting the address appear among root bus resources too.
> > > > > > > > > >
> > > > > > > > > > Curiously enough, pci_register_host_bridge() seems to try to add some
> > > > > > > > > > resource from that list into bus and it's what prints those "root bus
> > > > > > > > > > resource" lines and ee090000 is not among the printed lines despite
> > > > > > > > > > appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> > > > > > > > > > resources seems to be in disagreement and I'm not sure what to make of it.
> > > > > > > > > >
> > > > > > > > > > But before considering going into that direction or figuring out why this
> > > > > > > > > > ee090000 resource does not appear among root bus resources, could you
> > > > > > > > > > check if the attached patch changes behavior for the resource which are
> > > > > > > > > > non-zero based?
> > > > > > > > >
> > > > > > > > > This patch has no impact on dmesg, lspci output, or /proc/iomem
> > > > > > > > > for pci-rcar-gen2.
> > > > > > > >
> > > > > > > > It would have been too easy... :-(
> > > > > > > >
> > > > > > > > I'm sorry I don't really know these platform well and I'm currently trying
> > > > > > > > to understand what adds that ee090000 resource into the resource tree
> > > > > > > > and so far I've not been very successful.
> > > > > > > >
> > > > > > > > Perhaps it would be easiest to print a stacktrace when the resource is
> > > > > > > > added but there are many possible functions. I think all of them
> > > > > > > > converge in __request_resource() so I suggest adding:
> > > > > > > >
> > > > > > > > WARN_ON(new->start == 0xee090000);
> > > > > > > >
> > > > > > > > before __request_resource() does anything.
> > > > > > >
> > > > > > >     Call trace:
> > > > > > >      unwind_backtrace from show_stack+0x10/0x14
> > > > > > >      show_stack from dump_stack_lvl+0x7c/0xb0
> > > > > > >      dump_stack_lvl from __warn+0x80/0x198
> > > > > > >      __warn from warn_slowpath_fmt+0xc0/0x124
> > > > > > >      warn_slowpath_fmt from __request_resource+0x38/0xc8
> > > > > > >      __request_resource from __request_region+0xc4/0x1e8
> > > > > > >      __request_region from __devm_request_region+0x80/0xac
> > > > > > >      __devm_request_region from __devm_ioremap_resource+0xcc/0x160
> > > > > > >      __devm_ioremap_resource from rcar_pci_probe+0x58/0x350
> > > > > > >      rcar_pci_probe from platform_probe+0x58/0x90
> > > > > > >
> > > > > > > I.e. the call to devm_platform_get_and_ioremap_resource() in
> > > > > > > drivers/pci/controller/pci-rcar-gen2.c:rcar_pci_probe().
> > > > > >
> > > > > > Thanks, the patch below might help BAR0 (but I'm not sure if it's the
> > > > > > correct solution due to being so unfamiliar with these kind of platforms
> > > > > > and how they're initialized).
> > > > >
> > > > > Thanks, that has the following impact on dmesg:
> > > > >
> > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > >     -pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > >     +pci_bus 0000:00: root bus resource [mem 0xee080000-0xee090bff]
> > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
> > > > > PCI endpoint
> > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
> > > > > claim (no window)
> > > > >     -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> > > > > initial claim (no window)
> > > > >     +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > >      pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> > > > > PCI endpoint
> > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
> > > > > claim (no window)
> > > > >      pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > >      pci 0000:00:01.0: supports D1 D2
> > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
> > > > > PCI endpoint
> > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
> > > > > claim (no window)
> > > >
> > > > Did you e.g. forget to change pci_dbg() to pci_info() as these all went
> > > > away, I cannot see why it should disappear because of my patch?
> > > >
> > > > (No need to apologize if that was the case, just confirming if that
> > > > explains it is enough. :-))
> > >
> > > I indeed dropped that change. Adding it back...
> > >
> > > > >      pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > >      pci 0000:00:02.0: supports D1 D2
> > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > >
> > > > Perhaps print here what's the parent resource of these resource.
> > >
> > > pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned (parent
> > > [mem 0xee080000-0xee08ffff])
> > > pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned (parent
> > > [mem 0xee080000-0xee08ffff])
> >
> > Were these from a kernel without the problematic commit at all or with the
> > problematic commit and my fix? They look like the former case. The full
> > /proc/iomem also shows all the parent resources I think.
> 
> With commit 06b77d5647a4d6a7 ("PCI: Mark resources IORESOURCE_UNSET when
> outside bridge windows"), but without adding
> "pci_add_resource(&bridge->windows, cfg_res);" in .probe().
> 
> > > > >     -pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > >     +pci_bus 0000:00: resource 4 [mem 0xee080000-0xee090bff]
> > > > >      pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
> > > > >      PM: genpd_add_device: Add ee0d0000.pci to always-on
> > > > >      pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
> > > > >     @@ -414,26 +416,22 @@ PM: ==== always-on/ee0d0000.pci: start
> > > > >      pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
> > > > >      pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
> > > > >      pci_bus 0001:01: root bus resource [bus 01]
> > > > >     -pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
> > > > >     +pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0d0bff]
> > > > >      pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > >     -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial claim (no window)
> > > > >     -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
> > > > >     -pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no initial claim (no window)
> > > > >     +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
> > > > >      pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > >      pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > >     -pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial claim (no window)
> > > > >      pci 0001:01:01.0: BAR 0 [mem size 0x00001000]
> > > > >      pci 0001:01:01.0: supports D1 D2
> > > > >      pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
> > > > >      pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > >     -pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial claim (no window)
> > > > >      pci 0001:01:02.0: BAR 0 [mem size 0x00000100]
> > > > >      pci 0001:01:02.0: supports D1 D2
> > > > >      pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
> > > > >      PCI: bus1: Fast back to back transfers disabled
> > > > >      pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
> > > > >      pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
> > > > >     -pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
> > > > >     +pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0d0bff]
> > > > >      rcar-pcie fe000000.pcie: adding to PM domain always-on
> > > > >      PM: genpd_add_device: Add fe000000.pcie to always-on
> > > > >      rcar-pcie fe000000.pcie: host bridge /soc/pcie@fe000000 ranges:
> > > > >
> > > > > and on /proc/iomem (I used "diff -w" to reduce clutter):
> > > > >
> > > > >      ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
> > > > >      ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
> > > > >      ec740000-ec7401ff : ec500000.sound audmapp
> > > > >     -ee080000-ee08ffff : pci@ee090000
> > > >
> > > > So what did add this previous? (Maybe use the same WARN_ON() trick as
> > > > previously to find out.)
> > >
> > > First call:
> > >
> > >     + __request_resource from request_resource_conflict+0x24/0x3c
> > >     + request_resource_conflict from devm_request_resource+0x48/0x9c
> > >     + devm_request_resource from devm_request_pci_bus_resources+0x5c/0x70
> > >     + devm_request_pci_bus_resources from devm_of_pci_bridge_init+0x7c/0x1c0
> > >     + devm_of_pci_bridge_init from devm_pci_alloc_host_bridge+0x44/0x6c
> > >     + devm_pci_alloc_host_bridge from rcar_pci_probe+0x34/0x384
> > >     + rcar_pci_probe from platform_probe+0x58/0x90
> >
> > Thanks. So this is the call of interest, the rest are just the childs of
> > it with the same address.
> >
> > I'm looking devm_of_pci_get_host_bridge_resources(), it seems to read
> > "ranges" property but not "reg" at all.
> >
> > I wonder if devm_of_pci_get_host_bridge_resources() should also loop
> > through "reg" addresses and add those to host resources which are outside
> > of the "ranges"? Or if there should be a "range" that covers all what's
> > in "reg" to get them added into host bridge resources? That would seem the
> > generic solution instead of trying to do this in rcar_pci_probe().
> >
> > (Perhaps these are stupid questions, please excuse my lack of knowledge
> > about OF things.)
> >
> > While looking at another issue report, I also notice of_pci_prop_ranges()
> > assumes there are only bridge windows or BARs, but not both (not sure if
> > this relates to anything, just an observation while reading these code
> > paths).
> 
> We still have Rob in CC...

While we wait, can you simply try to make the "ranges" large enough to fit 
the BAR0 too?

I think it will results in making the larger "ranges" entry the parent of
ee090000-ee090bff : ee090000.pci pci@ee090000 entry in the resource tree
which would also avoid the coalescing issue.

Again, I'm not entirely sure if that would be an acceptable solution.

> > > Second call:
> > >
> > >     + __request_resource from allocate_resource+0x1b8/0x1d4
> > >     + allocate_resource from pci_bus_alloc_from_region+0x1e0/0x220
> > >     + pci_bus_alloc_from_region from pci_bus_alloc_resource+0x84/0xb8
> > >     + pci_bus_alloc_resource from _pci_assign_resource+0x78/0x150
> > >     + _pci_assign_resource from pci_assign_resource+0x10c/0x310
> > >     + pci_assign_resource from assign_requested_resources_sorted+0x78/0xac
> > >     + assign_requested_resources_sorted from
> > > __assign_resources_sorted+0x74/0x5c4
> > >     + __assign_resources_sorted from __pci_bus_assign_resources+0x50/0x1f0
> > >     + __pci_bus_assign_resources from
> > > pci_assign_unassigned_root_bus_resources+0xa8/0x190
> > >     + pci_assign_unassigned_root_bus_resources from pci_host_probe+0x5c/0xb0
> > >     + pci_host_probe from rcar_pci_probe+0x2e0/0x384
> > >     + rcar_pci_probe from platform_probe+0x58/0x90
> > >
> > > Third call:
> > >
> > >     + __request_resource from __request_region+0xc4/0x1e8
> > >     + __request_region from __devm_request_region+0x80/0xac
> > >     + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
> > >     + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
> > >     + pci_device_probe from really_probe+0x128/0x28c
> > >
> > > Fourth call:
> > >
> > >     + __request_region from __devm_request_region+0x80/0xac
> > >     + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
> > >     + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
> > >     + pci_device_probe from really_probe+0x128/0x28c
> > >
> > > Fifth call:
> > >
> > >     + __request_region from __devm_request_region+0x80/0xac
> > >     + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
> > >     + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
> > >     + pci_device_probe from really_probe+0x128/0x28c
> > >
> > > > It might have gotten broken because the coalesed resource
> > > > ee080000-ee090bff overlaps with that other resource in the resource tree.
> > > > But I don't see anything to that effect in the log so it's either silent
> > > > failure or there's much filtered from the log.
> > > >
> > > > >     -  ee080000-ee080fff : 0000:00:01.0
> > > > >          ee080000-ee080fff : ohci_hcd
> > > > >     -  ee081000-ee0810ff : 0000:00:02.0
> > > > >          ee081000-ee0810ff : ehci_hcd
> > > > >      ee090000-ee090bff : ee090000.pci pci@ee090000
> > > > >     -ee0c0000-ee0cffff : pci@ee0d0000
> > > > >     -  ee0c0000-ee0c0fff : 0001:01:01.0
> > > > >          ee0c0000-ee0c0fff : ohci_hcd
> > > > >     -  ee0c1000-ee0c10ff : 0001:01:02.0
> > > > >          ee0c1000-ee0c10ff : ehci_hcd
> > > > >      ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
> > > > >      ee100000-ee100327 : ee100000.mmc mmc@ee100000
> > > > >
> > > > > Removing the pci@ee0x0000 and 000x:0x:0x.0 entries doesn't look
> > > > > right to me? Or am I missing something?
> > > >
> > > > I cannot understand this output, these resources seem to have been now
> > > > left without a parent and due to -w I don't know what's their real
> > > > indentation level.
> > >
> > > The *_hcd resources are now at the top level.
> > >
> > >      ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
> > >      ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
> > >      ec740000-ec7401ff : ec500000.sound audmapp
> > >     -ee080000-ee08ffff : pci@ee090000
> > >     -  ee080000-ee080fff : 0000:00:01.0
> > >     -    ee080000-ee080fff : ohci_hcd
> > >     -  ee081000-ee0810ff : 0000:00:02.0
> > >     -    ee081000-ee0810ff : ehci_hcd
> > >     +ee080000-ee080fff : ohci_hcd
> > >     +ee081000-ee0810ff : ehci_hcd
> > >      ee090000-ee090bff : ee090000.pci pci@ee090000
> > >     -ee0c0000-ee0cffff : pci@ee0d0000
> > >     -  ee0c0000-ee0c0fff : 0001:01:01.0
> > >     -    ee0c0000-ee0c0fff : ohci_hcd
> > >     -  ee0c1000-ee0c10ff : 0001:01:02.0
> > >     -    ee0c1000-ee0c10ff : ehci_hcd
> > >     +ee0c0000-ee0c0fff : ohci_hcd
> > >     +ee0c1000-ee0c10ff : ehci_hcd
> > >      ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
> > >      ee100000-ee100327 : ee100000.mmc mmc@ee100000
> > >      ee140000-ee1400ff : ee140000.mmc mmc@ee140000
> > >
> > > I assume the others are gone because they now conflict with the *_hcd
> > > resources at the top level.
> >
> > Like you initially assumed, it is wrong (while it works as the resources
> > themselves don't care that much about their parent they're under as long
> > as the resource is assigned, it's still not intended to be that way).
> >
> > It might be worth to see if the coalescing in pci_register_host_bridge()
> > somehow messes these resources up either by not doing the coalesing loop
> > at all or by adding:
> >
> >                 if (res->parent || next_res->parent) {
> >                         if (res->parent)
> >                                 pr_info("Has parent %pR\n", res);
> >                         if (next_res->parent)
> >                                 pr_info("Has parent %pR\n", next_res);
> >                         continue;
> >                 }
> >
> > ...into the coalescing loop in case one of them happens to have a parent
> > (this is to be tested with the rcar_probe() fix).
> 
> The above restores the missing entries in /proc/iomem.
> Changes to dmesg:
> 
>      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
>      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff
> -> 0x00ee080000
>      pci-rcar-gen2 ee090000.pci: PCI: revision 11
>      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
>     +Has parent [mem 0xee080000-0xee08ffff]
>      pci_bus 0000:00: root bus resource [bus 00]
>      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
>     +pci_bus 0000:00: root bus resource [mem 0xee090000-0xee090bff]
>      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
> PCI endpoint
>     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
> claim (no window)
>     -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
>     +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
>      pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> initial claim (no window)
>      pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
>      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> PCI endpoint
>     @@ -403,21 +397,24 @@ pci 0000:00:02.0: BAR 0 [mem size 0x0000
>      pci 0000:00:02.0: supports D1 D2
>      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
>      PCI: bus0: Fast back to back transfers disabled
>      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
>      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
>      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
>     +pci_bus 0000:00: resource 5 [mem 0xee090000-0xee090bff]
>      pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
>      pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
>      pci-rcar-gen2 ee0d0000.pci:      MEM 0x00ee0c0000..0x00ee0cffff
> -> 0x00ee0c0000
>      pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
>      pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
>     +Has parent [mem 0xee0c0000-0xee0cffff]

So this ended up locating another bug in the coalescing loop.

It's very dangerous to mess with resources like that as the backing 
struct resource is shared with whatever added that resource, which is 
different sites in this case.

I'm preparing a better approach to do the resource merge, however, I'm 
left unsure if the clean up of everything will happen "correctly" as this 
coalescing is removing resources from the resource tree which were added 
there by something else so it's then becomes very muddy who is responsible 
for releasing it in the end.

>      pci_bus 0001:01: root bus resource [bus 01]
>      pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
>     +pci_bus 0001:01: root bus resource [mem 0xee0d0000-0xee0d0bff]
>      pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional
> PCI endpoint
>     -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial
> claim (no window)
>     -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
>     +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
>      pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> initial claim (no window)
>      pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
>      pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> PCI endpoint
>     @@ -431,9 +428,10 @@ pci 0001:01:02.0: BAR 0 [mem size 0x0000
>      pci 0001:01:02.0: supports D1 D2
>      pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
>      PCI: bus1: Fast back to back transfers disabled
>      pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
>      pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
>      pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
>     +pci_bus 0001:01: resource 5 [mem 0xee0d0000-0xee0d0bff]
> 
> > > > > > If this works, we'll also have to decide what to do with the BAR1 (it
> > > > > > didn't appear in your (partial?) /proc/iomem quote so I'm left unsure how
> > > > > > to approach it).
> > > > >
> > > > > That is indeed not visible in /proc/iomem.
> > > >
> > > > I meant before the commit 06b77d5647a4d6a7 ("PCI Mark resources
> > > > IORESOURCE_UNSET when outside bridge windows"), was it present?
> > >
> > > No, it was not present.
> > >
> > > > > I tried the following (whitespace-damaged):
> > > > >
> > > > > --- a/drivers/pci/controller/pci-rcar-gen2.c
> > > > > +++ b/drivers/pci/controller/pci-rcar-gen2.c
> > > > > @@ -179,6 +179,7 @@ static void rcar_pci_setup(struct rcar_pci *priv)
> > > > >         unsigned long window_size;
> > > > >         unsigned long window_addr;
> > > > >         unsigned long window_pci;
> > > > > +       struct resource res;
> > > > >         u32 val;
> > > > >
> > > > >         entry = resource_list_first_type(&bridge->dma_ranges, IORESOURCE_MEM);
> > > > > @@ -191,6 +192,8 @@ static void rcar_pci_setup(struct rcar_pci *priv)
> > > > >                 window_pci = entry->res->start - entry->offset;
> > > > >                 window_size = resource_size(entry->res);
> > > > >         }
> > > > > +       resource_set_range(&res, window_addr, window_size);
> > > >
> > > > You need to set flags properly too as this now tried to insert BUS, not
> > > > MEM resource (DEFINE_RES() might be the more appropriate in that case
> > > > anyway).
> > > >
> > > > However, if there's not &bridge->dma_ranges ranges entry, rcar_pci_setup()
> > > > seems to initialize the resource to 0x40000000-0x7fffffff and I'm not sure
> > >
> > > I guess the not &bridge->dma_ranges case dates back to the time the
> > > DTS didn't have dma-ranges yet.  However, upon closer look, the DTS
> > > still doesn't have dma_ranges, thus always using the default.
> > >
> > > > how it's supposed to work if there's more than one of these devices as per
> > > > the log above.
> > >
> > > Upon closer look, this is not a resource of the device, but an inbound
> > > memory region.  Hence there is no issue if multiple devices use the
> > > same region.
> > >
> > > >
> > > > > +       pci_add_resource(&bridge->windows, &res);
> > > >
> > > > What would be the backing resource in the resource tree for this? I'm not
> > > > sure if pci_add_resource() is going to result in adding one into the
> > > > resource tree.
> > >
> > > Likewise, it should not appear in /proc/ioem.
> >
> > Thanks for checking it out.
> >
> > I wonder how it would be supposed to work if PCI resource fitting logic
> > finds place for it and changes its address. I don't think it would ever
> > happen because it should never fit...
> >
> > ...But the logic still is a bit fishy if rcar2 code expects that address
> > to be fixed but doesn't flag the resource to have a fixed address.
> 
> How can the PCI resource fitting logic change it? It is an inbound
> memory region, not a normal BAR?

I thought it can happen because it appears as BAR1, all resources from 
BARs are eligible for the normal assignment but now that I think it more, 
the underlying struct resource is going different for that BAR1 and the 
actual dma_ranges entry.

-- 
 i.

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Kai-Heng Feng]

On 2025/10/8 1:30 AM, Ilpo Järvinen wrote:
> External email: Use caution opening links or attachments
> 
> 
> + Kai-Heng
> 
> On Mon, 6 Oct 2025, Geert Uytterhoeven wrote:
>> On Mon, 6 Oct 2025 at 14:37, Ilpo Järvinen
>> <ilpo.jarvinen@linux.intel.com> wrote:
>>> On Mon, 6 Oct 2025, Geert Uytterhoeven wrote:
>>>> On Fri, 3 Oct 2025 at 16:58, Ilpo Järvinen
>>>> <ilpo.jarvinen@linux.intel.com> wrote:
>>>>> On Fri, 3 Oct 2025, Geert Uytterhoeven wrote:
>>>>>> On Thu, 2 Oct 2025 at 18:59, Ilpo Järvinen
>>>>>> <ilpo.jarvinen@linux.intel.com> wrote:
>>>>>>> On Thu, 2 Oct 2025, Geert Uytterhoeven wrote:
>>>>>>>> On Thu, 2 Oct 2025 at 16:54, Ilpo Järvinen
>>>>>>>> <ilpo.jarvinen@linux.intel.com> wrote:
>>>>>>>>> On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
>>>>>>>>>> On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
>>>>>>>>>> <ilpo.jarvinen@linux.intel.com> wrote:
>>>>>>>>>>> On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
>>>>>>>>>>>> On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
>>>>>>>>>>>> <ilpo.jarvinen@linux.intel.com> wrote:
>>>>>>>>>>>>> On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
>>>>>>>>>>>>>> On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
>>>>>>>>>>>>>> <ilpo.jarvinen@linux.intel.com> wrote:
>>>>>>>>>>>>>>> PNP resources are checked for conflicts with the other resource in the
>>>>>>>>>>>>>>> system by quirk_system_pci_resources() that walks through all PCI
>>>>>>>>>>>>>>> resources. quirk_system_pci_resources() correctly filters out resource
>>>>>>>>>>>>>>> with IORESOURCE_UNSET.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Resources that do not reside within their bridge window, however, are
>>>>>>>>>>>>>>> not properly initialized with IORESOURCE_UNSET resulting in bogus
>>>>>>>>>>>>>>> conflicts detected in quirk_system_pci_resources():
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
>>>>>>>>>>>>>>> pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>> pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
>>>>>>>>>>>>>>> pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>> pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
>>>>>>>>>>>>>>> pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
>>>>>>>>>>>>>>> pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
>>>>>>>>>>>>>>> pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
>>>>>>>>>>>>>>> pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
>>>>>>>>>>>>>>> pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
>>>>>>>>>>>>>>> pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
>>>>>>>>>>>>>>> pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
>>>>>>>>>>>>>>> pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
>>>>>>>>>>>>>>> pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mark resources that are not contained within their bridge window with
>>>>>>>>>>>>>>> IORESOURCE_UNSET in __pci_read_base() which resolves the false
>>>>>>>>>>>>>>> positives for the overlap check in quirk_system_pci_resources().
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
>>>>>>>>>>>>>>> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
>>>>>>>>>>>>>> Mark resources IORESOURCE_UNSET when outside bridge windows") in
>>>>>>>>>>>>>> linux-next/master next-20250929 pci/next
>>>>>>>>>>>>
>>>>>>>>>>>>>> This replaces the actual resources by their sizes in the boot log on
>>>>>>>>>>>>>> e.g. on R-Car M2-W:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
>>>>>>>>>>>>>>       pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
>>>>>>>>>>>>>>       pci-rcar-gen2 ee090000.pci: PCI: revision 11
>>>>>>>>>>>>>>       pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
>>>>>>>>>>>>>>       pci_bus 0000:00: root bus resource [bus 00]
>>>>>>>>>>>>>>       pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
>>>>>>>>>>>>>>       pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
>>>>>>>>>>>>>>      -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
>>>>>>>>>>>>>>      -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
>>>>>>>>>>>>>
>>>>>>>>>>>>> What is going to be the parent of these resources? They don't seem to fall
>>>>>>>>>>>>> under the root bus resource above in which case the output change is
>>>>>>>>>>>>> intentional so they don't appear as if address range would be "okay".
>>>>>>>>>>>>
>>>>>>>>>>>> >From /proc/iomem:
>>>>>>>>>>>>
>>>>>>>>>>>>      ee080000-ee08ffff : pci@ee090000
>>>>>>>>>>>>        ee080000-ee080fff : 0000:00:01.0
>>>>>>>>>>>>          ee080000-ee080fff : ohci_hcd
>>>>>>>>>>>>        ee081000-ee0810ff : 0000:00:02.0
>>>>>>>>>>>>          ee081000-ee0810ff : ehci_hcd
>>>>>>>>>>>>      ee090000-ee090bff : ee090000.pci pci@ee090000
>>>>>>>>>>>
>>>>>>>>>>> Okay, so this seem to appear in the resource tree but not among the root
>>>>>>>>>>> bus resources.
>>>>>>>>>>>
>>>>>>>>>>>>      ee0c0000-ee0cffff : pci@ee0d0000
>>>>>>>>>>>>        ee0c0000-ee0c0fff : 0001:01:01.0
>>>>>>>>>>>>          ee0c0000-ee0c0fff : ohci_hcd
>>>>>>>>>>>>        ee0c1000-ee0c10ff : 0001:01:02.0
>>>>>>>>>>>>          ee0c1000-ee0c10ff : ehci_hcd
>>>>>>>>>>>>
>>>>>>>>>>>>> When IORESOURCE_UNSET is set in a resource, %pR does not print the start
>>>>>>>>>>>>> and end addresses.
>>>>>>>>>>>>
>>>>>>>>>>>> Yeah, that's how I found this commit, without bisecting ;-)
>>>>>>>>>>>>
>>>>>>>>>>>>>>      +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
>>>>>>>>>>>>>>      +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
>>>>>>>>>>>>>>       pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
>>>>>>>>>>>>>>      -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
>>>>>>>>>>>>>>      +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
>>>>>>>>>>>>>
>>>>>>>>>>>>> For this resource, it's very much intentional. It's a zero-based BAR which
>>>>>>>>>>>>> was left without IORESOURCE_UNSET prior to my patch leading to others part
>>>>>>>>>>>>> of the kernel to think that resource range valid and in use (in your
>>>>>>>>>>>>> case it's so small it wouldn't collide with anything but it wasn't
>>>>>>>>>>>>> properly set up resource, nonetheless).
>>>>>>>>>>>>>
>>>>>>>>>>>>>>       pci 0000:00:01.0: supports D1 D2
>>>>>>>>>>>>>>       pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
>>>>>>>>>>>>>>       pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
>>>>>>>>>>>>>>      -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
>>>>>>>>>>>>>>      +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
>>>>>>>>>>>>>
>>>>>>>>>>>>> And this as well is very much intentional.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>       pci 0000:00:02.0: supports D1 D2
>>>>>>>>>>>>>>       pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
>>>>>>>>>>>>>>       PCI: bus0: Fast back to back transfers disabled
>>>>>>>>>>>>>>       pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
>>>>>>>>>>>>>>       pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
>>>>>>>>>>>>>>       pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is that intentional?
>>>>>>>>>>>>>
>>>>>>>>>>>>> There's also that pci_dbg() in the patch which would show the original
>>>>>>>>>>>>> addresses (print the resource before setting IORESOURCE_UNSET) but to see
>>>>>>>>>>>>> it one would need to enable it with dyndbg=... Bjorn was thinking of
>>>>>>>>>>>>> making that pci_info() though so it would appear always.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
>>>>>>>>>>>>> getting assigned anywhere.
>>>>>>>>>>>>
>>>>>>>>>>>> The above log is almost complete (lacked enabling the device afterwards).
>>>>>>>>>>>>
>>>>>>>>>>>> AFAIU, the BARs come from the reg and ranges properties in the
>>>>>>>>>>>> PCI controller nodes;
>>>>>>>>>>>> https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
>>>>>>>>>>>
>>>>>>>>>>> Thanks, although I had already found this line by grep. I was just
>>>>>>>>>>> expecting the address appear among root bus resources too.
>>>>>>>>>>>
>>>>>>>>>>> Curiously enough, pci_register_host_bridge() seems to try to add some
>>>>>>>>>>> resource from that list into bus and it's what prints those "root bus
>>>>>>>>>>> resource" lines and ee090000 is not among the printed lines despite
>>>>>>>>>>> appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
>>>>>>>>>>> resources seems to be in disagreement and I'm not sure what to make of it.
>>>>>>>>>>>
>>>>>>>>>>> But before considering going into that direction or figuring out why this
>>>>>>>>>>> ee090000 resource does not appear among root bus resources, could you
>>>>>>>>>>> check if the attached patch changes behavior for the resource which are
>>>>>>>>>>> non-zero based?
>>>>>>>>>>
>>>>>>>>>> This patch has no impact on dmesg, lspci output, or /proc/iomem
>>>>>>>>>> for pci-rcar-gen2.
>>>>>>>>>
>>>>>>>>> It would have been too easy... :-(
>>>>>>>>>
>>>>>>>>> I'm sorry I don't really know these platform well and I'm currently trying
>>>>>>>>> to understand what adds that ee090000 resource into the resource tree
>>>>>>>>> and so far I've not been very successful.
>>>>>>>>>
>>>>>>>>> Perhaps it would be easiest to print a stacktrace when the resource is
>>>>>>>>> added but there are many possible functions. I think all of them
>>>>>>>>> converge in __request_resource() so I suggest adding:
>>>>>>>>>
>>>>>>>>> WARN_ON(new->start == 0xee090000);
>>>>>>>>>
>>>>>>>>> before __request_resource() does anything.
>>>>>>>>
>>>>>>>>      Call trace:
>>>>>>>>       unwind_backtrace from show_stack+0x10/0x14
>>>>>>>>       show_stack from dump_stack_lvl+0x7c/0xb0
>>>>>>>>       dump_stack_lvl from __warn+0x80/0x198
>>>>>>>>       __warn from warn_slowpath_fmt+0xc0/0x124
>>>>>>>>       warn_slowpath_fmt from __request_resource+0x38/0xc8
>>>>>>>>       __request_resource from __request_region+0xc4/0x1e8
>>>>>>>>       __request_region from __devm_request_region+0x80/0xac
>>>>>>>>       __devm_request_region from __devm_ioremap_resource+0xcc/0x160
>>>>>>>>       __devm_ioremap_resource from rcar_pci_probe+0x58/0x350
>>>>>>>>       rcar_pci_probe from platform_probe+0x58/0x90
>>>>>>>>
>>>>>>>> I.e. the call to devm_platform_get_and_ioremap_resource() in
>>>>>>>> drivers/pci/controller/pci-rcar-gen2.c:rcar_pci_probe().
>>>>>>>
>>>>>>> Thanks, the patch below might help BAR0 (but I'm not sure if it's the
>>>>>>> correct solution due to being so unfamiliar with these kind of platforms
>>>>>>> and how they're initialized).
>>>>>>
>>>>>> Thanks, that has the following impact on dmesg:
>>>>>>
>>>>>>       pci-rcar-gen2 ee090000.pci: PCI: revision 11
>>>>>>       pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
>>>>>>       pci_bus 0000:00: root bus resource [bus 00]
>>>>>>      -pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
>>>>>>      +pci_bus 0000:00: root bus resource [mem 0xee080000-0xee090bff]
>>>>>>       pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
>>>>>> PCI endpoint
>>>>>>      -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
>>>>>> claim (no window)
>>>>>>      -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
>>>>>>      -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
>>>>>> initial claim (no window)
>>>>>>      +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
>>>>>>       pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
>>>>>>       pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
>>>>>> PCI endpoint
>>>>>>      -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
>>>>>> claim (no window)
>>>>>>       pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
>>>>>>       pci 0000:00:01.0: supports D1 D2
>>>>>>       pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
>>>>>>       pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
>>>>>> PCI endpoint
>>>>>>      -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
>>>>>> claim (no window)
>>>>>
>>>>> Did you e.g. forget to change pci_dbg() to pci_info() as these all went
>>>>> away, I cannot see why it should disappear because of my patch?
>>>>>
>>>>> (No need to apologize if that was the case, just confirming if that
>>>>> explains it is enough. :-))
>>>>
>>>> I indeed dropped that change. Adding it back...
>>>>
>>>>>>       pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
>>>>>>       pci 0000:00:02.0: supports D1 D2
>>>>>>       pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
>>>>>>       PCI: bus0: Fast back to back transfers disabled
>>>>>>       pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
>>>>>>       pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
>>>>>
>>>>> Perhaps print here what's the parent resource of these resource.
>>>>
>>>> pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned (parent
>>>> [mem 0xee080000-0xee08ffff])
>>>> pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned (parent
>>>> [mem 0xee080000-0xee08ffff])
>>>
>>> Were these from a kernel without the problematic commit at all or with the
>>> problematic commit and my fix? They look like the former case. The full
>>> /proc/iomem also shows all the parent resources I think.
>>
>> With commit 06b77d5647a4d6a7 ("PCI: Mark resources IORESOURCE_UNSET when
>> outside bridge windows"), but without adding
>> "pci_add_resource(&bridge->windows, cfg_res);" in .probe().
>>
>>>>>>      -pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
>>>>>>      +pci_bus 0000:00: resource 4 [mem 0xee080000-0xee090bff]
>>>>>>       pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
>>>>>>       PM: genpd_add_device: Add ee0d0000.pci to always-on
>>>>>>       pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
>>>>>>      @@ -414,26 +416,22 @@ PM: ==== always-on/ee0d0000.pci: start
>>>>>>       pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
>>>>>>       pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
>>>>>>       pci_bus 0001:01: root bus resource [bus 01]
>>>>>>      -pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
>>>>>>      +pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0d0bff]
>>>>>>       pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
>>>>>>      -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial claim (no window)
>>>>>>      -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
>>>>>>      -pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no initial claim (no window)
>>>>>>      +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
>>>>>>       pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
>>>>>>       pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
>>>>>>      -pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial claim (no window)
>>>>>>       pci 0001:01:01.0: BAR 0 [mem size 0x00001000]
>>>>>>       pci 0001:01:01.0: supports D1 D2
>>>>>>       pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
>>>>>>       pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
>>>>>>      -pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial claim (no window)
>>>>>>       pci 0001:01:02.0: BAR 0 [mem size 0x00000100]
>>>>>>       pci 0001:01:02.0: supports D1 D2
>>>>>>       pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
>>>>>>       PCI: bus1: Fast back to back transfers disabled
>>>>>>       pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
>>>>>>       pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
>>>>>>      -pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
>>>>>>      +pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0d0bff]
>>>>>>       rcar-pcie fe000000.pcie: adding to PM domain always-on
>>>>>>       PM: genpd_add_device: Add fe000000.pcie to always-on
>>>>>>       rcar-pcie fe000000.pcie: host bridge /soc/pcie@fe000000 ranges:
>>>>>>
>>>>>> and on /proc/iomem (I used "diff -w" to reduce clutter):
>>>>>>
>>>>>>       ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
>>>>>>       ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
>>>>>>       ec740000-ec7401ff : ec500000.sound audmapp
>>>>>>      -ee080000-ee08ffff : pci@ee090000
>>>>>
>>>>> So what did add this previous? (Maybe use the same WARN_ON() trick as
>>>>> previously to find out.)
>>>>
>>>> First call:
>>>>
>>>>      + __request_resource from request_resource_conflict+0x24/0x3c
>>>>      + request_resource_conflict from devm_request_resource+0x48/0x9c
>>>>      + devm_request_resource from devm_request_pci_bus_resources+0x5c/0x70
>>>>      + devm_request_pci_bus_resources from devm_of_pci_bridge_init+0x7c/0x1c0
>>>>      + devm_of_pci_bridge_init from devm_pci_alloc_host_bridge+0x44/0x6c
>>>>      + devm_pci_alloc_host_bridge from rcar_pci_probe+0x34/0x384
>>>>      + rcar_pci_probe from platform_probe+0x58/0x90
>>>
>>> Thanks. So this is the call of interest, the rest are just the childs of
>>> it with the same address.
>>>
>>> I'm looking devm_of_pci_get_host_bridge_resources(), it seems to read
>>> "ranges" property but not "reg" at all.
>>>
>>> I wonder if devm_of_pci_get_host_bridge_resources() should also loop
>>> through "reg" addresses and add those to host resources which are outside
>>> of the "ranges"? Or if there should be a "range" that covers all what's
>>> in "reg" to get them added into host bridge resources? That would seem the
>>> generic solution instead of trying to do this in rcar_pci_probe().
>>>
>>> (Perhaps these are stupid questions, please excuse my lack of knowledge
>>> about OF things.)
>>>
>>> While looking at another issue report, I also notice of_pci_prop_ranges()
>>> assumes there are only bridge windows or BARs, but not both (not sure if
>>> this relates to anything, just an observation while reading these code
>>> paths).
>>
>> We still have Rob in CC...
> 
> While we wait, can you simply try to make the "ranges" large enough to fit
> the BAR0 too?
> 
> I think it will results in making the larger "ranges" entry the parent of
> ee090000-ee090bff : ee090000.pci pci@ee090000 entry in the resource tree
> which would also avoid the coalescing issue.
> 
> Again, I'm not entirely sure if that would be an acceptable solution.
> 
>>>> Second call:
>>>>
>>>>      + __request_resource from allocate_resource+0x1b8/0x1d4
>>>>      + allocate_resource from pci_bus_alloc_from_region+0x1e0/0x220
>>>>      + pci_bus_alloc_from_region from pci_bus_alloc_resource+0x84/0xb8
>>>>      + pci_bus_alloc_resource from _pci_assign_resource+0x78/0x150
>>>>      + _pci_assign_resource from pci_assign_resource+0x10c/0x310
>>>>      + pci_assign_resource from assign_requested_resources_sorted+0x78/0xac
>>>>      + assign_requested_resources_sorted from
>>>> __assign_resources_sorted+0x74/0x5c4
>>>>      + __assign_resources_sorted from __pci_bus_assign_resources+0x50/0x1f0
>>>>      + __pci_bus_assign_resources from
>>>> pci_assign_unassigned_root_bus_resources+0xa8/0x190
>>>>      + pci_assign_unassigned_root_bus_resources from pci_host_probe+0x5c/0xb0
>>>>      + pci_host_probe from rcar_pci_probe+0x2e0/0x384
>>>>      + rcar_pci_probe from platform_probe+0x58/0x90
>>>>
>>>> Third call:
>>>>
>>>>      + __request_resource from __request_region+0xc4/0x1e8
>>>>      + __request_region from __devm_request_region+0x80/0xac
>>>>      + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
>>>>      + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
>>>>      + pci_device_probe from really_probe+0x128/0x28c
>>>>
>>>> Fourth call:
>>>>
>>>>      + __request_region from __devm_request_region+0x80/0xac
>>>>      + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
>>>>      + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
>>>>      + pci_device_probe from really_probe+0x128/0x28c
>>>>
>>>> Fifth call:
>>>>
>>>>      + __request_region from __devm_request_region+0x80/0xac
>>>>      + __devm_request_region from usb_hcd_pci_probe+0x15c/0x35c
>>>>      + usb_hcd_pci_probe from pci_device_probe+0x94/0x104
>>>>      + pci_device_probe from really_probe+0x128/0x28c
>>>>
>>>>> It might have gotten broken because the coalesed resource
>>>>> ee080000-ee090bff overlaps with that other resource in the resource tree.
>>>>> But I don't see anything to that effect in the log so it's either silent
>>>>> failure or there's much filtered from the log.
>>>>>
>>>>>>      -  ee080000-ee080fff : 0000:00:01.0
>>>>>>           ee080000-ee080fff : ohci_hcd
>>>>>>      -  ee081000-ee0810ff : 0000:00:02.0
>>>>>>           ee081000-ee0810ff : ehci_hcd
>>>>>>       ee090000-ee090bff : ee090000.pci pci@ee090000
>>>>>>      -ee0c0000-ee0cffff : pci@ee0d0000
>>>>>>      -  ee0c0000-ee0c0fff : 0001:01:01.0
>>>>>>           ee0c0000-ee0c0fff : ohci_hcd
>>>>>>      -  ee0c1000-ee0c10ff : 0001:01:02.0
>>>>>>           ee0c1000-ee0c10ff : ehci_hcd
>>>>>>       ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
>>>>>>       ee100000-ee100327 : ee100000.mmc mmc@ee100000
>>>>>>
>>>>>> Removing the pci@ee0x0000 and 000x:0x:0x.0 entries doesn't look
>>>>>> right to me? Or am I missing something?
>>>>>
>>>>> I cannot understand this output, these resources seem to have been now
>>>>> left without a parent and due to -w I don't know what's their real
>>>>> indentation level.
>>>>
>>>> The *_hcd resources are now at the top level.
>>>>
>>>>       ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
>>>>       ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
>>>>       ec740000-ec7401ff : ec500000.sound audmapp
>>>>      -ee080000-ee08ffff : pci@ee090000
>>>>      -  ee080000-ee080fff : 0000:00:01.0
>>>>      -    ee080000-ee080fff : ohci_hcd
>>>>      -  ee081000-ee0810ff : 0000:00:02.0
>>>>      -    ee081000-ee0810ff : ehci_hcd
>>>>      +ee080000-ee080fff : ohci_hcd
>>>>      +ee081000-ee0810ff : ehci_hcd
>>>>       ee090000-ee090bff : ee090000.pci pci@ee090000
>>>>      -ee0c0000-ee0cffff : pci@ee0d0000
>>>>      -  ee0c0000-ee0c0fff : 0001:01:01.0
>>>>      -    ee0c0000-ee0c0fff : ohci_hcd
>>>>      -  ee0c1000-ee0c10ff : 0001:01:02.0
>>>>      -    ee0c1000-ee0c10ff : ehci_hcd
>>>>      +ee0c0000-ee0c0fff : ohci_hcd
>>>>      +ee0c1000-ee0c10ff : ehci_hcd
>>>>       ee0d0000-ee0d0bff : ee0d0000.pci pci@ee0d0000
>>>>       ee100000-ee100327 : ee100000.mmc mmc@ee100000
>>>>       ee140000-ee1400ff : ee140000.mmc mmc@ee140000
>>>>
>>>> I assume the others are gone because they now conflict with the *_hcd
>>>> resources at the top level.
>>>
>>> Like you initially assumed, it is wrong (while it works as the resources
>>> themselves don't care that much about their parent they're under as long
>>> as the resource is assigned, it's still not intended to be that way).
>>>
>>> It might be worth to see if the coalescing in pci_register_host_bridge()
>>> somehow messes these resources up either by not doing the coalesing loop
>>> at all or by adding:
>>>
>>>                  if (res->parent || next_res->parent) {
>>>                          if (res->parent)
>>>                                  pr_info("Has parent %pR\n", res);
>>>                          if (next_res->parent)
>>>                                  pr_info("Has parent %pR\n", next_res);
>>>                          continue;
>>>                  }
>>>
>>> ...into the coalescing loop in case one of them happens to have a parent
>>> (this is to be tested with the rcar_probe() fix).
>>
>> The above restores the missing entries in /proc/iomem.
>> Changes to dmesg:
>>
>>       pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
>>       pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff
>> -> 0x00ee080000
>>       pci-rcar-gen2 ee090000.pci: PCI: revision 11
>>       pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
>>      +Has parent [mem 0xee080000-0xee08ffff]
>>       pci_bus 0000:00: root bus resource [bus 00]
>>       pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
>>      +pci_bus 0000:00: root bus resource [mem 0xee090000-0xee090bff]
>>       pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
>> PCI endpoint
>>      -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
>> claim (no window)
>>      -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
>>      +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
>>       pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
>> initial claim (no window)
>>       pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
>>       pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
>> PCI endpoint
>>      @@ -403,21 +397,24 @@ pci 0000:00:02.0: BAR 0 [mem size 0x0000
>>       pci 0000:00:02.0: supports D1 D2
>>       pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
>>       PCI: bus0: Fast back to back transfers disabled
>>       pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
>>       pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
>>       pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
>>      +pci_bus 0000:00: resource 5 [mem 0xee090000-0xee090bff]
>>       pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
>>       pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
>>       pci-rcar-gen2 ee0d0000.pci:      MEM 0x00ee0c0000..0x00ee0cffff
>> -> 0x00ee0c0000
>>       pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
>>       pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
>>      +Has parent [mem 0xee0c0000-0xee0cffff]
> 
> So this ended up locating another bug in the coalescing loop.
> 
> It's very dangerous to mess with resources like that as the backing
> struct resource is shared with whatever added that resource, which is
> different sites in this case.
> 
> I'm preparing a better approach to do the resource merge, however, I'm
> left unsure if the clean up of everything will happen "correctly" as this
> coalescing is removing resources from the resource tree which were added
> there by something else so it's then becomes very muddy who is responsible
> for releasing it in the end.

So what about a helper function pci_try_contiguous_apertures() to allocate 
across resources when single resource isn't large enough?

Anyway, I am happy to try your new approach.

Kai-Heng

> 
>>       pci_bus 0001:01: root bus resource [bus 01]
>>       pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
>>      +pci_bus 0001:01: root bus resource [mem 0xee0d0000-0xee0d0bff]
>>       pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional
>> PCI endpoint
>>      -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial
>> claim (no window)
>>      -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
>>      +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
>>       pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
>> initial claim (no window)
>>       pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
>>       pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional
>> PCI endpoint
>>      @@ -431,9 +428,10 @@ pci 0001:01:02.0: BAR 0 [mem size 0x0000
>>       pci 0001:01:02.0: supports D1 D2
>>       pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
>>       PCI: bus1: Fast back to back transfers disabled
>>       pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
>>       pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
>>       pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
>>      +pci_bus 0001:01: resource 5 [mem 0xee0d0000-0xee0d0bff]
>>
>>>>>>> If this works, we'll also have to decide what to do with the BAR1 (it
>>>>>>> didn't appear in your (partial?) /proc/iomem quote so I'm left unsure how
>>>>>>> to approach it).
>>>>>>
>>>>>> That is indeed not visible in /proc/iomem.
>>>>>
>>>>> I meant before the commit 06b77d5647a4d6a7 ("PCI Mark resources
>>>>> IORESOURCE_UNSET when outside bridge windows"), was it present?
>>>>
>>>> No, it was not present.
>>>>
>>>>>> I tried the following (whitespace-damaged):
>>>>>>
>>>>>> --- a/drivers/pci/controller/pci-rcar-gen2.c
>>>>>> +++ b/drivers/pci/controller/pci-rcar-gen2.c
>>>>>> @@ -179,6 +179,7 @@ static void rcar_pci_setup(struct rcar_pci *priv)
>>>>>>          unsigned long window_size;
>>>>>>          unsigned long window_addr;
>>>>>>          unsigned long window_pci;
>>>>>> +       struct resource res;
>>>>>>          u32 val;
>>>>>>
>>>>>>          entry = resource_list_first_type(&bridge->dma_ranges, IORESOURCE_MEM);
>>>>>> @@ -191,6 +192,8 @@ static void rcar_pci_setup(struct rcar_pci *priv)
>>>>>>                  window_pci = entry->res->start - entry->offset;
>>>>>>                  window_size = resource_size(entry->res);
>>>>>>          }
>>>>>> +       resource_set_range(&res, window_addr, window_size);
>>>>>
>>>>> You need to set flags properly too as this now tried to insert BUS, not
>>>>> MEM resource (DEFINE_RES() might be the more appropriate in that case
>>>>> anyway).
>>>>>
>>>>> However, if there's not &bridge->dma_ranges ranges entry, rcar_pci_setup()
>>>>> seems to initialize the resource to 0x40000000-0x7fffffff and I'm not sure
>>>>
>>>> I guess the not &bridge->dma_ranges case dates back to the time the
>>>> DTS didn't have dma-ranges yet.  However, upon closer look, the DTS
>>>> still doesn't have dma_ranges, thus always using the default.
>>>>
>>>>> how it's supposed to work if there's more than one of these devices as per
>>>>> the log above.
>>>>
>>>> Upon closer look, this is not a resource of the device, but an inbound
>>>> memory region.  Hence there is no issue if multiple devices use the
>>>> same region.
>>>>
>>>>>
>>>>>> +       pci_add_resource(&bridge->windows, &res);
>>>>>
>>>>> What would be the backing resource in the resource tree for this? I'm not
>>>>> sure if pci_add_resource() is going to result in adding one into the
>>>>> resource tree.
>>>>
>>>> Likewise, it should not appear in /proc/ioem.
>>>
>>> Thanks for checking it out.
>>>
>>> I wonder how it would be supposed to work if PCI resource fitting logic
>>> finds place for it and changes its address. I don't think it would ever
>>> happen because it should never fit...
>>>
>>> ...But the logic still is a bit fishy if rcar2 code expects that address
>>> to be fixed but doesn't flag the resource to have a fixed address.
>>
>> How can the PCI resource fitting logic change it? It is an inbound
>> memory region, not a normal BAR?
> 
> I thought it can happen because it appears as BAR1, all resources from
> BARs are eligible for the normal assignment but now that I think it more,
> the underlying struct resource is going different for that BAR1 and the
> actual dma_ranges entry.
> 
> --
>   i.

Re: [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET

[Geert Uytterhoeven]

Hi Ilpo,

On Tue, 7 Oct 2025 at 19:30, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> On Mon, 6 Oct 2025, Geert Uytterhoeven wrote:
> > On Mon, 6 Oct 2025 at 14:37, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > On Mon, 6 Oct 2025, Geert Uytterhoeven wrote:
> > > > On Fri, 3 Oct 2025 at 16:58, Ilpo Järvinen
> > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > On Fri, 3 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > On Thu, 2 Oct 2025 at 18:59, Ilpo Järvinen
> > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > On Thu, 2 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > > On Thu, 2 Oct 2025 at 16:54, Ilpo Järvinen
> > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > > > > On Wed, 1 Oct 2025 at 15:06, Ilpo Järvinen
> > > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > > On Wed, 1 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > > > > > > > On Tue, 30 Sept 2025 at 18:32, Ilpo Järvinen
> > > > > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > > > > On Tue, 30 Sep 2025, Geert Uytterhoeven wrote:
> > > > > > > > > > > > > > On Fri, 26 Sept 2025 at 04:40, Ilpo Järvinen
> > > > > > > > > > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > > > > > > > > > PNP resources are checked for conflicts with the other resource in the
> > > > > > > > > > > > > > > system by quirk_system_pci_resources() that walks through all PCI
> > > > > > > > > > > > > > > resources. quirk_system_pci_resources() correctly filters out resource
> > > > > > > > > > > > > > > with IORESOURCE_UNSET.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Resources that do not reside within their bridge window, however, are
> > > > > > > > > > > > > > > not properly initialized with IORESOURCE_UNSET resulting in bogus
> > > > > > > > > > > > > > > conflicts detected in quirk_system_pci_resources():
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
> > > > > > > > > > > > > > > pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
> > > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x1ffffffff 64bit pref]
> > > > > > > > > > > > > > > pci 0000:03:00.0: VF BAR 2 [mem 0x00000000-0x3dffffffff 64bit pref]: contains BAR 2 for 31 VFs
> > > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > > pnp 00:04: disabling [mem 0xfc000000-0xfc00ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
> > > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfedc0000-0xfedc7fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfeda0000-0xfeda0fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfeda1000-0xfeda1fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xc0000000-0xcfffffff disabled] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed20000-0xfed7ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed90000-0xfed93fff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfed45000-0xfed8ffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > > pnp 00:05: disabling [mem 0xfee00000-0xfeefffff] because it overlaps 0000:03:00.0 BAR 9 [mem 0x00000000-0x3dffffffff 64bit pref]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Mark resources that are not contained within their bridge window with
> > > > > > > > > > > > > > > IORESOURCE_UNSET in __pci_read_base() which resolves the false
> > > > > > > > > > > > > > > positives for the overlap check in quirk_system_pci_resources().
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Fixes: f7834c092c42 ("PNP: Don't check for overlaps with unassigned PCI BARs")
> > > > > > > > > > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks for your patch, which is now commit 06b77d5647a4d6a7 ("PCI:
> > > > > > > > > > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows") in
> > > > > > > > > > > > > > linux-next/master next-20250929 pci/next
> > > > > > > > > > > >
> > > > > > > > > > > > > > This replaces the actual resources by their sizes in the boot log on
> > > > > > > > > > > > > > e.g. on R-Car M2-W:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
> > > > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000
> > > > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > > > > > > > > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > > > > > > > > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > > > > > > > > > > >      pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > > > > > > > > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > > > > > > > > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > > > > > > > > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > > > > > > > > > > > >
> > > > > > > > > > > > > What is going to be the parent of these resources? They don't seem to fall
> > > > > > > > > > > > > under the root bus resource above in which case the output change is
> > > > > > > > > > > > > intentional so they don't appear as if address range would be "okay".
> > > > > > > > > > > >
> > > > > > > > > > > > >From /proc/iomem:
> > > > > > > > > > > >
> > > > > > > > > > > >     ee080000-ee08ffff : pci@ee090000
> > > > > > > > > > > >       ee080000-ee080fff : 0000:00:01.0
> > > > > > > > > > > >         ee080000-ee080fff : ohci_hcd
> > > > > > > > > > > >       ee081000-ee0810ff : 0000:00:02.0
> > > > > > > > > > > >         ee081000-ee0810ff : ehci_hcd
> > > > > > > > > > > >     ee090000-ee090bff : ee090000.pci pci@ee090000
> > > > > > > > > > >
> > > > > > > > > > > Okay, so this seem to appear in the resource tree but not among the root
> > > > > > > > > > > bus resources.
> > > > > > > > > > >
> > > > > > > > > > > >     ee0c0000-ee0cffff : pci@ee0d0000
> > > > > > > > > > > >       ee0c0000-ee0c0fff : 0001:01:01.0
> > > > > > > > > > > >         ee0c0000-ee0c0fff : ohci_hcd
> > > > > > > > > > > >       ee0c1000-ee0c10ff : 0001:01:02.0
> > > > > > > > > > > >         ee0c1000-ee0c10ff : ehci_hcd
> > > > > > > > > > > >
> > > > > > > > > > > > > When IORESOURCE_UNSET is set in a resource, %pR does not print the start
> > > > > > > > > > > > > and end addresses.
> > > > > > > > > > > >
> > > > > > > > > > > > Yeah, that's how I found this commit, without bisecting ;-)
> > > > > > > > > > > >
> > > > > > > > > > > > > >     +pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > > > > > > > > > > >     +pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > > > > > > > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > > > > > > > > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]
> > > > > > > > > > > > > >     +pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > > > > > > > > > >
> > > > > > > > > > > > > For this resource, it's very much intentional. It's a zero-based BAR which
> > > > > > > > > > > > > was left without IORESOURCE_UNSET prior to my patch leading to others part
> > > > > > > > > > > > > of the kernel to think that resource range valid and in use (in your
> > > > > > > > > > > > > case it's so small it wouldn't collide with anything but it wasn't
> > > > > > > > > > > > > properly set up resource, nonetheless).
> > > > > > > > > > > > >
> > > > > > > > > > > > > >      pci 0000:00:01.0: supports D1 D2
> > > > > > > > > > > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > > > > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > > > > > > > > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]
> > > > > > > > > > > > > >     +pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > > > > > > > > > >
> > > > > > > > > > > > > And this as well is very much intentional.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >      pci 0000:00:02.0: supports D1 D2
> > > > > > > > > > > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > > > > > > > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > > > > > > > > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > > > > > > > > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > > > > > > > > > > >      pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Is that intentional?
> > > > > > > > > > > > >
> > > > > > > > > > > > > There's also that pci_dbg() in the patch which would show the original
> > > > > > > > > > > > > addresses (print the resource before setting IORESOURCE_UNSET) but to see
> > > > > > > > > > > > > it one would need to enable it with dyndbg=... Bjorn was thinking of
> > > > > > > > > > > > > making that pci_info() though so it would appear always.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Was this the entire PCI related diff? I don't see those 0000:00:00.0 BARs
> > > > > > > > > > > > > getting assigned anywhere.
> > > > > > > > > > > >
> > > > > > > > > > > > The above log is almost complete (lacked enabling the device afterwards).
> > > > > > > > > > > >
> > > > > > > > > > > > AFAIU, the BARs come from the reg and ranges properties in the
> > > > > > > > > > > > PCI controller nodes;
> > > > > > > > > > > > https://elixir.bootlin.com/linux/v6.17/source/arch/arm/boot/dts/renesas/r8a7791.dtsi#L1562
> > > > > > > > > > >
> > > > > > > > > > > Thanks, although I had already found this line by grep. I was just
> > > > > > > > > > > expecting the address appear among root bus resources too.
> > > > > > > > > > >
> > > > > > > > > > > Curiously enough, pci_register_host_bridge() seems to try to add some
> > > > > > > > > > > resource from that list into bus and it's what prints those "root bus
> > > > > > > > > > > resource" lines and ee090000 is not among the printed lines despite
> > > > > > > > > > > appearing in /proc/iomem. As is, the resource tree and PCI bus view on the
> > > > > > > > > > > resources seems to be in disagreement and I'm not sure what to make of it.
> > > > > > > > > > >
> > > > > > > > > > > But before considering going into that direction or figuring out why this
> > > > > > > > > > > ee090000 resource does not appear among root bus resources, could you
> > > > > > > > > > > check if the attached patch changes behavior for the resource which are
> > > > > > > > > > > non-zero based?
> > > > > > > > > >
> > > > > > > > > > This patch has no impact on dmesg, lspci output, or /proc/iomem
> > > > > > > > > > for pci-rcar-gen2.
> > > > > > > > >
> > > > > > > > > It would have been too easy... :-(
> > > > > > > > >
> > > > > > > > > I'm sorry I don't really know these platform well and I'm currently trying
> > > > > > > > > to understand what adds that ee090000 resource into the resource tree
> > > > > > > > > and so far I've not been very successful.
> > > > > > > > >
> > > > > > > > > Perhaps it would be easiest to print a stacktrace when the resource is
> > > > > > > > > added but there are many possible functions. I think all of them
> > > > > > > > > converge in __request_resource() so I suggest adding:
> > > > > > > > >
> > > > > > > > > WARN_ON(new->start == 0xee090000);
> > > > > > > > >
> > > > > > > > > before __request_resource() does anything.
> > > > > > > >
> > > > > > > >     Call trace:
> > > > > > > >      unwind_backtrace from show_stack+0x10/0x14
> > > > > > > >      show_stack from dump_stack_lvl+0x7c/0xb0
> > > > > > > >      dump_stack_lvl from __warn+0x80/0x198
> > > > > > > >      __warn from warn_slowpath_fmt+0xc0/0x124
> > > > > > > >      warn_slowpath_fmt from __request_resource+0x38/0xc8
> > > > > > > >      __request_resource from __request_region+0xc4/0x1e8
> > > > > > > >      __request_region from __devm_request_region+0x80/0xac
> > > > > > > >      __devm_request_region from __devm_ioremap_resource+0xcc/0x160
> > > > > > > >      __devm_ioremap_resource from rcar_pci_probe+0x58/0x350
> > > > > > > >      rcar_pci_probe from platform_probe+0x58/0x90
> > > > > > > >
> > > > > > > > I.e. the call to devm_platform_get_and_ioremap_resource() in
> > > > > > > > drivers/pci/controller/pci-rcar-gen2.c:rcar_pci_probe().
> > > > > > >
> > > > > > > Thanks, the patch below might help BAR0 (but I'm not sure if it's the
> > > > > > > correct solution due to being so unfamiliar with these kind of platforms
> > > > > > > and how they're initialized).
> > > > > >
> > > > > > Thanks, that has the following impact on dmesg:
> > > > > >
> > > > > >      pci-rcar-gen2 ee090000.pci: PCI: revision 11
> > > > > >      pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
> > > > > >      pci_bus 0000:00: root bus resource [bus 00]
> > > > > >     -pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
> > > > > >     +pci_bus 0000:00: root bus resource [mem 0xee080000-0xee090bff]
> > > > > >      pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
> > > > > > PCI endpoint
> > > > > >     -pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]: no initial
> > > > > > claim (no window)
> > > > > >     -pci 0000:00:00.0: BAR 0 [mem size 0x00000400]
> > > > > >     -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no
> > > > > > initial claim (no window)
> > > > > >     +pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
> > > > > >      pci 0000:00:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > >      pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310 conventional
> > > > > > PCI endpoint
> > > > > >     -pci 0000:00:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial
> > > > > > claim (no window)
> > > > > >      pci 0000:00:01.0: BAR 0 [mem size 0x00001000]
> > > > > >      pci 0000:00:01.0: supports D1 D2
> > > > > >      pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > >      pci 0000:00:02.0: [1033:00e0] type 00 class 0x0c0320 conventional
> > > > > > PCI endpoint
> > > > > >     -pci 0000:00:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial
> > > > > > claim (no window)
> > > > >
> > > > > Did you e.g. forget to change pci_dbg() to pci_info() as these all went
> > > > > away, I cannot see why it should disappear because of my patch?
> > > > >
> > > > > (No need to apologize if that was the case, just confirming if that
> > > > > explains it is enough. :-))
> > > >
> > > > I indeed dropped that change. Adding it back...
> > > >
> > > > > >      pci 0000:00:02.0: BAR 0 [mem size 0x00000100]
> > > > > >      pci 0000:00:02.0: supports D1 D2
> > > > > >      pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > >      PCI: bus0: Fast back to back transfers disabled
> > > > > >      pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
> > > > > >      pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
> > > > >
> > > > > Perhaps print here what's the parent resource of these resource.
> > > >
> > > > pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned (parent
> > > > [mem 0xee080000-0xee08ffff])
> > > > pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned (parent
> > > > [mem 0xee080000-0xee08ffff])
> > >
> > > Were these from a kernel without the problematic commit at all or with the
> > > problematic commit and my fix? They look like the former case. The full
> > > /proc/iomem also shows all the parent resources I think.
> >
> > With commit 06b77d5647a4d6a7 ("PCI: Mark resources IORESOURCE_UNSET when
> > outside bridge windows"), but without adding
> > "pci_add_resource(&bridge->windows, cfg_res);" in .probe().
> >
> > > > > >     -pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
> > > > > >     +pci_bus 0000:00: resource 4 [mem 0xee080000-0xee090bff]
> > > > > >      pci-rcar-gen2 ee0d0000.pci: adding to PM domain always-on
> > > > > >      PM: genpd_add_device: Add ee0d0000.pci to always-on
> > > > > >      pci-rcar-gen2 ee0d0000.pci: host bridge /soc/pci@ee0d0000 ranges:
> > > > > >     @@ -414,26 +416,22 @@ PM: ==== always-on/ee0d0000.pci: start
> > > > > >      pci-rcar-gen2 ee0d0000.pci: PCI: revision 11
> > > > > >      pci-rcar-gen2 ee0d0000.pci: PCI host bridge to bus 0001:01
> > > > > >      pci_bus 0001:01: root bus resource [bus 01]
> > > > > >     -pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0cffff]
> > > > > >     +pci_bus 0001:01: root bus resource [mem 0xee0c0000-0xee0d0bff]
> > > > > >      pci 0001:01:00.0: [1033:0000] type 00 class 0x060000 conventional PCI endpoint
> > > > > >     -pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]: no initial claim (no window)
> > > > > >     -pci 0001:01:00.0: BAR 0 [mem size 0x00000400]
> > > > > >     -pci 0001:01:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]: no initial claim (no window)
> > > > > >     +pci 0001:01:00.0: BAR 0 [mem 0xee0d0800-0xee0d0bff]
> > > > > >      pci 0001:01:00.0: BAR 1 [mem size 0x40000000 pref]
> > > > > >      pci 0001:01:01.0: [1033:0035] type 00 class 0x0c0310 conventional PCI endpoint
> > > > > >     -pci 0001:01:01.0: BAR 0 [mem 0x00000000-0x00000fff]: no initial claim (no window)
> > > > > >      pci 0001:01:01.0: BAR 0 [mem size 0x00001000]
> > > > > >      pci 0001:01:01.0: supports D1 D2
> > > > > >      pci 0001:01:01.0: PME# supported from D0 D1 D2 D3hot
> > > > > >      pci 0001:01:02.0: [1033:00e0] type 00 class 0x0c0320 conventional PCI endpoint
> > > > > >     -pci 0001:01:02.0: BAR 0 [mem 0x00000000-0x000000ff]: no initial claim (no window)
> > > > > >      pci 0001:01:02.0: BAR 0 [mem size 0x00000100]
> > > > > >      pci 0001:01:02.0: supports D1 D2
> > > > > >      pci 0001:01:02.0: PME# supported from D0 D1 D2 D3hot
> > > > > >      PCI: bus1: Fast back to back transfers disabled
> > > > > >      pci 0001:01:01.0: BAR 0 [mem 0xee0c0000-0xee0c0fff]: assigned
> > > > > >      pci 0001:01:02.0: BAR 0 [mem 0xee0c1000-0xee0c10ff]: assigned
> > > > > >     -pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0cffff]
> > > > > >     +pci_bus 0001:01: resource 4 [mem 0xee0c0000-0xee0d0bff]
> > > > > >      rcar-pcie fe000000.pcie: adding to PM domain always-on
> > > > > >      PM: genpd_add_device: Add fe000000.pcie to always-on
> > > > > >      rcar-pcie fe000000.pcie: host bridge /soc/pcie@fe000000 ranges:
> > > > > >
> > > > > > and on /proc/iomem (I used "diff -w" to reduce clutter):
> > > > > >
> > > > > >      ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
> > > > > >      ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
> > > > > >      ec740000-ec7401ff : ec500000.sound audmapp
> > > > > >     -ee080000-ee08ffff : pci@ee090000
> > > > >
> > > > > So what did add this previous? (Maybe use the same WARN_ON() trick as
> > > > > previously to find out.)
> > > >
> > > > First call:
> > > >
> > > >     + __request_resource from request_resource_conflict+0x24/0x3c
> > > >     + request_resource_conflict from devm_request_resource+0x48/0x9c
> > > >     + devm_request_resource from devm_request_pci_bus_resources+0x5c/0x70
> > > >     + devm_request_pci_bus_resources from devm_of_pci_bridge_init+0x7c/0x1c0
> > > >     + devm_of_pci_bridge_init from devm_pci_alloc_host_bridge+0x44/0x6c
> > > >     + devm_pci_alloc_host_bridge from rcar_pci_probe+0x34/0x384
> > > >     + rcar_pci_probe from platform_probe+0x58/0x90
> > >
> > > Thanks. So this is the call of interest, the rest are just the childs of
> > > it with the same address.
> > >
> > > I'm looking devm_of_pci_get_host_bridge_resources(), it seems to read
> > > "ranges" property but not "reg" at all.
> > >
> > > I wonder if devm_of_pci_get_host_bridge_resources() should also loop
> > > through "reg" addresses and add those to host resources which are outside
> > > of the "ranges"? Or if there should be a "range" that covers all what's
> > > in "reg" to get them added into host bridge resources? That would seem the
> > > generic solution instead of trying to do this in rcar_pci_probe().
> > >
> > > (Perhaps these are stupid questions, please excuse my lack of knowledge
> > > about OF things.)
> > >
> > > While looking at another issue report, I also notice of_pci_prop_ranges()
> > > assumes there are only bridge windows or BARs, but not both (not sure if
> > > this relates to anything, just an observation while reading these code
> > > paths).
> >
> > We still have Rob in CC...
>
> While we wait, can you simply try to make the "ranges" large enough to fit
> the BAR0 too?

Sure, so I changed:

    --- a/arch/arm/boot/dts/renesas/r8a7791.dtsi
    +++ b/arch/arm/boot/dts/renesas/r8a7791.dtsi
    @@ -1577,7 +1577,7 @@ pci0: pci@ee090000 {
                            #address-cells = <3>;
                            #size-cells = <2>;
                            #interrupt-cells = <1>;
    -                       ranges = <0x02000000 0 0xee080000 0
0xee080000 0 0x00010000>;
    +                       ranges = <0x02000000 0 0xee080000 0
0xee080000 0 0x00020000>;
                            interrupt-map-mask = <0xf800 0 0 0x7>;
                            interrupt-map = <0x0000 0 0 1 &gic GIC_SPI
108 IRQ_TYPE_LEVEL_HIGH>,
                                            <0x0800 0 0 1 &gic GIC_SPI
108 IRQ_TYPE_LEVEL_HIGH>,

> I think it will results in making the larger "ranges" entry the parent of
> ee090000-ee090bff : ee090000.pci pci@ee090000 entry in the resource tree

Correct!

Impact on dmesg:

     pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:
    -pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff
-> 0x00ee080000
    +pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee09ffff
-> 0x00ee080000
     rcar_pci_setup:187: No dma_ranges, using default!
     pci-rcar-gen2 ee090000.pci: PCI: revision 11
     pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00
    -Has parent [mem 0xee080000-0xee08ffff]
    +Has parent [mem 0xee080000-0xee09ffff]
     pci_bus 0000:00: root bus resource [bus 00]
    -pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
    +pci_bus 0000:00: root bus resource [mem 0xee080000-0xee09ffff]
     pci_bus 0000:00: root bus resource [mem 0xee090000-0xee090bff]
     pci 0000:00:00.0: [1033:0000] type 00 class 0x060000 conventional
PCI endpoint
     pci 0000:00:00.0: BAR 0 [mem 0xee090800-0xee090bff]
    @@ -397,9 +398,9 @@ pci 0000:00:02.0: BAR 0 [mem size 0x0000
     pci 0000:00:02.0: supports D1 D2
     pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
     PCI: bus0: Fast back to back transfers disabled
    -pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
(parent [mem 0xee080000-0xee08ffff])
    -pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
(parent [mem 0xee080000-0xee08ffff])
    -pci_bus 0000:00: resource 4 [mem 0xee080000-0xee08ffff]
    +pci 0000:00:01.0: BAR 0 [mem 0xee080000-0xee080fff]: assigned
(parent [mem 0xee080000-0xee09ffff])
    +pci 0000:00:02.0: BAR 0 [mem 0xee081000-0xee0810ff]: assigned
(parent [mem 0xee080000-0xee09ffff])
    +pci_bus 0000:00: resource 4 [mem 0xee080000-0xee09ffff]
     pci_bus 0000:00: resource 5 [mem 0xee090000-0xee090bff]


Impact on /proc/iomem:

     ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000
     ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000
     ec740000-ec7401ff : ec500000.sound audmapp
    -ee080000-ee08ffff : pci@ee090000
    +ee080000-ee09ffff : pci@ee090000
       ee080000-ee080fff : 0000:00:01.0
         ee080000-ee080fff : ohci_hcd
       ee081000-ee0810ff : 0000:00:02.0
         ee081000-ee0810ff : ehci_hcd
    -ee090000-ee090bff : ee090000.pci pci@ee090000
    +  ee090000-ee090bff : ee090000.pci pci@ee090000
     ee0c0000-ee0cffff : pci@ee0d0000
       ee0c0000-ee0c0fff : 0001:01:01.0
         ee0c0000-ee0c0fff : ohci_hcd


> which would also avoid the coalescing issue.

Also correct: I can remove the coalescing workaround again without
having any impact on /proc/iomem.

> Again, I'm not entirely sure if that would be an acceptable solution.

I am afraid not, as it should keep on working with existing DTBs,
as per the stable DT ABI rule.
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/2] PCI: Fix bogus resource overlaps

[Bjorn Helgaas]

On Wed, Sep 24, 2025 at 04:42:26PM +0300, Ilpo Järvinen wrote:
> Hi all,
> 
> I noticed a few bogus resource overlaps in logs which occurred for PNP
> resource addresses that collided with large zero-based resources
> (typically IOV resources). It turns out, the problem boils down to not
> marking resources properly with IORESOURCE_UNSET when BAR is read into
> the struct resource.
> 
> I've long wanted to mark resource not within their window with
> IORESOURCE_UNSET as done in patch 2, however, my first attempt to do it
> failed because the bridge window resources were not yet available. I
> assumed the bridge window change would require more extensive changes
> and postponed it, but it turns there were no big complications from it
> (at least so far).
> 
> But things may be more complicated than I know so if you think there's
> a good reason why the filling of bridge resources is delayed to the
> second read, please speak up!
> 
> There are extra notes in both patches under --- line, please check
> them as well.
> 
> This series does not removed the second read of the bridge resources,
> it's probably unnecessary work now but confirming that requires more
> testing and code reading than I currently have time for so just sending
> the obvious fix series out (and adding a TODO entry for myself for
> later).
> 
> Ilpo Järvinen (2):
>   PCI: Setup bridge resources earlier
>   PCI: Resources outside their window must set IORESOURCE_UNSET
> 
>  drivers/pci/probe.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 42 insertions(+), 3 deletions(-)

Applied to pci/resource for v6.18, thanks!