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
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
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
>
>
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
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
>
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
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
>
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.
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
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.
© 2016 - 2025 Red Hat, Inc.