drivers/pci/probe.c | 26 +++---- include/linux/ioport.h | 5 ++ include/linux/resource_ext.h | 3 + kernel/resource.c | 139 ++++++++++++++++++++++++++++++++++- kernel/resource_kunit.c | 121 ++++++++++++++++++++++++++++++ 5 files changed, 279 insertions(+), 15 deletions(-)
Hi, Here's a series for Geert to test if this fixes the improper coalescing of resources as was experienced with the pci_add_resource() change (I know the breaking change was pulled before 6.18 main PR but I'd want to retry it later once the known issues have been addressed). The expected result is there'll be two adjacent host bridge resources in the resource tree as the different name should disallow coalescing them together, and therefore BAR0 has a window into which it belongs to. Generic info for the series: PCI host bridge windows were coalesced in place into one of the structs on the resources list. The host bridge window coalescing code does not know who holds references and still needs the struct resource it's coalescing from/to so it is safer to perform coalescing into entirely a new struct resource instead and leave the old resource addresses as they were. The checks when coalescing is allowed are also made stricter so that only resources that have identical the metadata can be coalesced. As a bonus, there's also a bit of framework to easily create kunit tests for resource tree functions (beyond just resource_coalesce()). Ilpo Järvinen (3): PCI: Refactor host bridge window coalescing loop to use prev PCI: Do not coalesce host bridge resource structs in place resource, kunit: add test case for resource_coalesce() drivers/pci/probe.c | 26 +++---- include/linux/ioport.h | 5 ++ include/linux/resource_ext.h | 3 + kernel/resource.c | 139 ++++++++++++++++++++++++++++++++++- kernel/resource_kunit.c | 121 ++++++++++++++++++++++++++++++ 5 files changed, 279 insertions(+), 15 deletions(-) base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585 -- 2.39.5
Hi Ilpo,
On Fri, 10 Oct 2025 at 16:42, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> Here's a series for Geert to test if this fixes the improper coalescing
> of resources as was experienced with the pci_add_resource() change (I
> know the breaking change was pulled before 6.18 main PR but I'd want to
> retry it later once the known issues have been addressed). The expected
> result is there'll be two adjacent host bridge resources in the
> resource tree as the different name should disallow coalescing them
> together, and therefore BAR0 has a window into which it belongs to.
>
> Generic info for the series:
>
> PCI host bridge windows were coalesced in place into one of the structs
> on the resources list. The host bridge window coalescing code does not
> know who holds references and still needs the struct resource it's
> coalescing from/to so it is safer to perform coalescing into entirely
> a new struct resource instead and leave the old resource addresses as
> they were.
>
> The checks when coalescing is allowed are also made stricter so that
> only resources that have identical the metadata can be coalesced.
>
> As a bonus, there's also a bit of framework to easily create kunit
> tests for resource tree functions (beyond just resource_coalesce()).
>
> Ilpo Järvinen (3):
> PCI: Refactor host bridge window coalescing loop to use prev
> PCI: Do not coalesce host bridge resource structs in place
> resource, kunit: add test case for resource_coalesce()
Thanks for your series!
I have applied this on top of commit 06b77d5647a4d6a7 ("PCI:
Mark resources IORESOURCE_UNSET when outside bridge windows"), and
gave it a a try on Koelsch (R-Car M2-W).
Impact on dmesg (for the first PCI/USB) instance:
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]: 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]: 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 0000:00:01.0: enabling device (0140 -> 0142)
pci 0000:00:02.0: enabling device (0140 -> 0142)
I.e. the "no initial claim (no window)" messages introduced by commit
06b77d5647a4d6a7 are no longer seen.
The BARs still show "mem size <n>" instead of the "mem <start>-<end>"
before commit 06b77d5647a4d6a7, though.
This series has not impact on /proc/iomem, or on the output of
"lspci -v" (commit 06b77d5647a4d6a7 also had no impact here).
I.e. the part of /proc/iomem related to the first PCI/USB instance
still looks like:
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
I hope this matches your expectation.s
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 Mon, 20 Oct 2025, Geert Uytterhoeven wrote:
> On Fri, 10 Oct 2025 at 16:42, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > Here's a series for Geert to test if this fixes the improper coalescing
> > of resources as was experienced with the pci_add_resource() change (I
> > know the breaking change was pulled before 6.18 main PR but I'd want to
> > retry it later once the known issues have been addressed). The expected
> > result is there'll be two adjacent host bridge resources in the
> > resource tree as the different name should disallow coalescing them
> > together, and therefore BAR0 has a window into which it belongs to.
> >
> > Generic info for the series:
> >
> > PCI host bridge windows were coalesced in place into one of the structs
> > on the resources list. The host bridge window coalescing code does not
> > know who holds references and still needs the struct resource it's
> > coalescing from/to so it is safer to perform coalescing into entirely
> > a new struct resource instead and leave the old resource addresses as
> > they were.
> >
> > The checks when coalescing is allowed are also made stricter so that
> > only resources that have identical the metadata can be coalesced.
> >
> > As a bonus, there's also a bit of framework to easily create kunit
> > tests for resource tree functions (beyond just resource_coalesce()).
> >
> > Ilpo Järvinen (3):
> > PCI: Refactor host bridge window coalescing loop to use prev
> > PCI: Do not coalesce host bridge resource structs in place
> > resource, kunit: add test case for resource_coalesce()
>
> Thanks for your series!
>
> I have applied this on top of commit 06b77d5647a4d6a7 ("PCI:
> Mark resources IORESOURCE_UNSET when outside bridge windows"), and
> gave it a a try on Koelsch (R-Car M2-W).
So the pci_bus_add_resource() patch to rcar_pci_probe() was not included?
No coalescing would be attempted without that change.
With the pci_bus_add_resource() patch, the resource name is different, I
think, so even then it should abort coalescing the ranges with this
series.
> Impact on dmesg (for the first PCI/USB) instance:
>
> 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]: 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]: 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 0000:00:01.0: enabling device (0140 -> 0142)
> pci 0000:00:02.0: enabling device (0140 -> 0142)
>
> I.e. the "no initial claim (no window)" messages introduced by commit
> 06b77d5647a4d6a7 are no longer seen.
Is that perhaps again because of pci_dbg() vs pci_info()?
> The BARs still show "mem size <n>" instead of the "mem <start>-<end>"
> before commit 06b77d5647a4d6a7, though.
To me this looks like UNSET was still set for these resources. Missing the
pci_bus_add_resource() patch would explain that and if the pci_dbg()
wasn't printed, it would explain both symptoms.
Once these questions are resolved, I'll ask Rob what is the preferred
solution here, a) driver doing pci_bus_add_resource() or b) including it
into the DT ranges (if we could fix the ranges).
We likely need to go with a) to preserve backwards compatibility but I
also want to understand how those ranges are supposed to be used if we
wouldn't have historical baggage.
(I appreciate following through even if the original series is now
reverted!)
> This series has not impact on /proc/iomem, or on the output of
> "lspci -v" (commit 06b77d5647a4d6a7 also had no impact here).
> I.e. the part of /proc/iomem related to the first PCI/USB instance
> still looks like:
>
> 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
>
> I hope this matches your expectation.s
>
> Gr{oetje,eeting}s,
>
> Geert
>
>
--
i.
Hi Ilpo,
On Mon, 20 Oct 2025 at 18:20, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> On Mon, 20 Oct 2025, Geert Uytterhoeven wrote:
> > On Fri, 10 Oct 2025 at 16:42, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > Here's a series for Geert to test if this fixes the improper coalescing
> > > of resources as was experienced with the pci_add_resource() change (I
> > > know the breaking change was pulled before 6.18 main PR but I'd want to
> > > retry it later once the known issues have been addressed). The expected
> > > result is there'll be two adjacent host bridge resources in the
> > > resource tree as the different name should disallow coalescing them
> > > together, and therefore BAR0 has a window into which it belongs to.
> > >
> > > Generic info for the series:
> > >
> > > PCI host bridge windows were coalesced in place into one of the structs
> > > on the resources list. The host bridge window coalescing code does not
> > > know who holds references and still needs the struct resource it's
> > > coalescing from/to so it is safer to perform coalescing into entirely
> > > a new struct resource instead and leave the old resource addresses as
> > > they were.
> > >
> > > The checks when coalescing is allowed are also made stricter so that
> > > only resources that have identical the metadata can be coalesced.
> > >
> > > As a bonus, there's also a bit of framework to easily create kunit
> > > tests for resource tree functions (beyond just resource_coalesce()).
> > >
> > > Ilpo Järvinen (3):
> > > PCI: Refactor host bridge window coalescing loop to use prev
> > > PCI: Do not coalesce host bridge resource structs in place
> > > resource, kunit: add test case for resource_coalesce()
> >
> > Thanks for your series!
> >
> > I have applied this on top of commit 06b77d5647a4d6a7 ("PCI:
> > Mark resources IORESOURCE_UNSET when outside bridge windows"), and
> > gave it a a try on Koelsch (R-Car M2-W).
>
> So the pci_bus_add_resource() patch to rcar_pci_probe() was not included?
> No coalescing would be attempted without that change.
Sorry, I didn't realize you wanted that (and anything else) to be
included, too. Please tell me the exact base I should use for testing,
and I will give it another run.
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 Tue, 21 Oct 2025, Geert Uytterhoeven wrote:
> On Mon, 20 Oct 2025 at 18:20, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Mon, 20 Oct 2025, Geert Uytterhoeven wrote:
> > > On Fri, 10 Oct 2025 at 16:42, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > Here's a series for Geert to test if this fixes the improper coalescing
> > > > of resources as was experienced with the pci_add_resource() change (I
> > > > know the breaking change was pulled before 6.18 main PR but I'd want to
> > > > retry it later once the known issues have been addressed). The expected
> > > > result is there'll be two adjacent host bridge resources in the
> > > > resource tree as the different name should disallow coalescing them
> > > > together, and therefore BAR0 has a window into which it belongs to.
> > > >
> > > > Generic info for the series:
> > > >
> > > > PCI host bridge windows were coalesced in place into one of the structs
> > > > on the resources list. The host bridge window coalescing code does not
> > > > know who holds references and still needs the struct resource it's
> > > > coalescing from/to so it is safer to perform coalescing into entirely
> > > > a new struct resource instead and leave the old resource addresses as
> > > > they were.
> > > >
> > > > The checks when coalescing is allowed are also made stricter so that
> > > > only resources that have identical the metadata can be coalesced.
> > > >
> > > > As a bonus, there's also a bit of framework to easily create kunit
> > > > tests for resource tree functions (beyond just resource_coalesce()).
> > > >
> > > > Ilpo Järvinen (3):
> > > > PCI: Refactor host bridge window coalescing loop to use prev
> > > > PCI: Do not coalesce host bridge resource structs in place
> > > > resource, kunit: add test case for resource_coalesce()
> > >
> > > Thanks for your series!
> > >
> > > I have applied this on top of commit 06b77d5647a4d6a7 ("PCI:
> > > Mark resources IORESOURCE_UNSET when outside bridge windows"), and
> > > gave it a a try on Koelsch (R-Car M2-W).
> >
> > So the pci_bus_add_resource() patch to rcar_pci_probe() was not included?
> > No coalescing would be attempted without that change.
>
> Sorry, I didn't realize you wanted that (and anything else) to be
> included, too. Please tell me the exact base I should use for testing,
> and I will give it another run.
I'm sorry, it's indeed a bit confusing as some of these patches never
have been in Linus' tree.
So I'm interested on what's the result with these changes/series together:
[PATCH 1/2] PCI: Setup bridge resources earlier
[PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET
[PATCH 1/1] PCI: rcar-gen2: Add BAR0 into host bridge resources
[PATCH 1/3] PCI: Refactor host bridge window coalescing loop to use prev
[PATCH 2/3] PCI: Do not coalesce host bridge resource structs in place
[PATCH 3/3] resource, kunit: add test case for resource_coalesce()
You might also want to change that pci_dbg() in the IORESOURCE_UNSET patch
to pci_info() (as otherwise dyndbg is necessary to make it visible).
Lore links to these series/patches:
https://lore.kernel.org/linux-pci/20250924134228.1663-1-ilpo.jarvinen@linux.intel.com/
https://lore.kernel.org/linux-pci/7640a03e-dfea-db9c-80f5-d80fa2c505b7@linux.intel.com/
https://lore.kernel.org/linux-pci/20251010144231.15773-1-ilpo.jarvinen@linux.intel.com/
The expected result is that those usb resources are properly parented and
the ee080000-ee08ffff and ee090000-ee090bff are not coalesced together (as
that would destroy information). So something along the lines of:
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
--
i.
Hi Ilpo,
On Tue, 21 Oct 2025 at 13:54, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> On Tue, 21 Oct 2025, Geert Uytterhoeven wrote:
> > On Mon, 20 Oct 2025 at 18:20, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > On Mon, 20 Oct 2025, Geert Uytterhoeven wrote:
> > > > On Fri, 10 Oct 2025 at 16:42, Ilpo Järvinen
> > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > Here's a series for Geert to test if this fixes the improper coalescing
> > > > > of resources as was experienced with the pci_add_resource() change (I
> > > > > know the breaking change was pulled before 6.18 main PR but I'd want to
> > > > > retry it later once the known issues have been addressed). The expected
> > > > > result is there'll be two adjacent host bridge resources in the
> > > > > resource tree as the different name should disallow coalescing them
> > > > > together, and therefore BAR0 has a window into which it belongs to.
> > > > >
> > > > > Generic info for the series:
> > > > >
> > > > > PCI host bridge windows were coalesced in place into one of the structs
> > > > > on the resources list. The host bridge window coalescing code does not
> > > > > know who holds references and still needs the struct resource it's
> > > > > coalescing from/to so it is safer to perform coalescing into entirely
> > > > > a new struct resource instead and leave the old resource addresses as
> > > > > they were.
> > > > >
> > > > > The checks when coalescing is allowed are also made stricter so that
> > > > > only resources that have identical the metadata can be coalesced.
> > > > >
> > > > > As a bonus, there's also a bit of framework to easily create kunit
> > > > > tests for resource tree functions (beyond just resource_coalesce()).
> > > > >
> > > > > Ilpo Järvinen (3):
> > > > > PCI: Refactor host bridge window coalescing loop to use prev
> > > > > PCI: Do not coalesce host bridge resource structs in place
> > > > > resource, kunit: add test case for resource_coalesce()
> > > >
> > > > Thanks for your series!
> > > >
> > > > I have applied this on top of commit 06b77d5647a4d6a7 ("PCI:
> > > > Mark resources IORESOURCE_UNSET when outside bridge windows"), and
> > > > gave it a a try on Koelsch (R-Car M2-W).
> > >
> > > So the pci_bus_add_resource() patch to rcar_pci_probe() was not included?
> > > No coalescing would be attempted without that change.
> >
> > Sorry, I didn't realize you wanted that (and anything else) to be
> > included, too. Please tell me the exact base I should use for testing,
> > and I will give it another run.
>
> I'm sorry, it's indeed a bit confusing as some of these patches never
> have been in Linus' tree.
>
> So I'm interested on what's the result with these changes/series together:
>
> [PATCH 1/2] PCI: Setup bridge resources earlier
> [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET
> [PATCH 1/1] PCI: rcar-gen2: Add BAR0 into host bridge resources
> [PATCH 1/3] PCI: Refactor host bridge window coalescing loop to use prev
> [PATCH 2/3] PCI: Do not coalesce host bridge resource structs in place
> [PATCH 3/3] resource, kunit: add test case for resource_coalesce()
>
> You might also want to change that pci_dbg() in the IORESOURCE_UNSET patch
> to pci_info() (as otherwise dyndbg is necessary to make it visible).
Thanks, all done:
$ git cherry -v --abbrev=1 v6.18-rc2^
+ 211ddde0 Linux 6.18-rc2
+ 3fdaf2 PCI: Setup bridge resources earlier
+ 5be02e5 PCI: Resources outside their window must set IORESOURCE_UNSET
+ adf6f11 PCI: rcar-gen2: Add BAR0 into host bridge resources
+ eecb500 PCI: Refactor host bridge window coalescing loop to use prev
+ 60470b3 PCI: Do not coalesce host bridge resource structs in place
+ afe3ec resource, kunit: add test case for resource_coalesce()
+ 487c98 Use dev_info() in drivers/pci/probe.c:__pci_read_base()
IORESOURCE_UNSET path
Compared to v6.18-rc2, dmesg changed (for the first PCI/USB instance)
like:
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_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]
-pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
+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_bus 0000:00: resource 5 [mem 0xee090000-0xee090bff]
pci 0000:00:01.0: enabling device (0140 -> 0142)
pci 0000:00:02.0: enabling device (0140 -> 0142)
> The expected result is that those usb resources are properly parented and
> the ee080000-ee08ffff and ee090000-ee090bff are not coalesced together (as
> that would destroy information). So something along the lines of:
>
> 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
Compared to v6.18-rc2, the output of "lspci -v" or "cat /proc/iomem"
did not change. Hence for the two PCI/USB instances:
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
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, 22 Oct 2025, Geert Uytterhoeven wrote:
> On Tue, 21 Oct 2025 at 13:54, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Tue, 21 Oct 2025, Geert Uytterhoeven wrote:
> > > On Mon, 20 Oct 2025 at 18:20, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > On Mon, 20 Oct 2025, Geert Uytterhoeven wrote:
> > > > > On Fri, 10 Oct 2025 at 16:42, Ilpo Järvinen
> > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > Here's a series for Geert to test if this fixes the improper coalescing
> > > > > > of resources as was experienced with the pci_add_resource() change (I
> > > > > > know the breaking change was pulled before 6.18 main PR but I'd want to
> > > > > > retry it later once the known issues have been addressed). The expected
> > > > > > result is there'll be two adjacent host bridge resources in the
> > > > > > resource tree as the different name should disallow coalescing them
> > > > > > together, and therefore BAR0 has a window into which it belongs to.
> > > > > >
> > > > > > Generic info for the series:
> > > > > >
> > > > > > PCI host bridge windows were coalesced in place into one of the structs
> > > > > > on the resources list. The host bridge window coalescing code does not
> > > > > > know who holds references and still needs the struct resource it's
> > > > > > coalescing from/to so it is safer to perform coalescing into entirely
> > > > > > a new struct resource instead and leave the old resource addresses as
> > > > > > they were.
> > > > > >
> > > > > > The checks when coalescing is allowed are also made stricter so that
> > > > > > only resources that have identical the metadata can be coalesced.
> > > > > >
> > > > > > As a bonus, there's also a bit of framework to easily create kunit
> > > > > > tests for resource tree functions (beyond just resource_coalesce()).
> > > > > >
> > > > > > Ilpo Järvinen (3):
> > > > > > PCI: Refactor host bridge window coalescing loop to use prev
> > > > > > PCI: Do not coalesce host bridge resource structs in place
> > > > > > resource, kunit: add test case for resource_coalesce()
> > > > >
> > > > > Thanks for your series!
> > > > >
> > > > > I have applied this on top of commit 06b77d5647a4d6a7 ("PCI:
> > > > > Mark resources IORESOURCE_UNSET when outside bridge windows"), and
> > > > > gave it a a try on Koelsch (R-Car M2-W).
> > > >
> > > > So the pci_bus_add_resource() patch to rcar_pci_probe() was not included?
> > > > No coalescing would be attempted without that change.
> > >
> > > Sorry, I didn't realize you wanted that (and anything else) to be
> > > included, too. Please tell me the exact base I should use for testing,
> > > and I will give it another run.
> >
> > I'm sorry, it's indeed a bit confusing as some of these patches never
> > have been in Linus' tree.
> >
> > So I'm interested on what's the result with these changes/series together:
> >
> > [PATCH 1/2] PCI: Setup bridge resources earlier
> > [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET
> > [PATCH 1/1] PCI: rcar-gen2: Add BAR0 into host bridge resources
> > [PATCH 1/3] PCI: Refactor host bridge window coalescing loop to use prev
> > [PATCH 2/3] PCI: Do not coalesce host bridge resource structs in place
> > [PATCH 3/3] resource, kunit: add test case for resource_coalesce()
> >
> > You might also want to change that pci_dbg() in the IORESOURCE_UNSET patch
> > to pci_info() (as otherwise dyndbg is necessary to make it visible).
>
> Thanks, all done:
>
> $ git cherry -v --abbrev=1 v6.18-rc2^
> + 211ddde0 Linux 6.18-rc2
> + 3fdaf2 PCI: Setup bridge resources earlier
> + 5be02e5 PCI: Resources outside their window must set IORESOURCE_UNSET
> + adf6f11 PCI: rcar-gen2: Add BAR0 into host bridge resources
> + eecb500 PCI: Refactor host bridge window coalescing loop to use prev
> + 60470b3 PCI: Do not coalesce host bridge resource structs in place
> + afe3ec resource, kunit: add test case for resource_coalesce()
> + 487c98 Use dev_info() in drivers/pci/probe.c:__pci_read_base()
> IORESOURCE_UNSET path
>
> Compared to v6.18-rc2, dmesg changed (for the first PCI/USB instance)
> like:
>
> 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_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]
> -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> +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_bus 0000:00: resource 5 [mem 0xee090000-0xee090bff]
> pci 0000:00:01.0: enabling device (0140 -> 0142)
> pci 0000:00:02.0: enabling device (0140 -> 0142)
>
> > The expected result is that those usb resources are properly parented and
> > the ee080000-ee08ffff and ee090000-ee090bff are not coalesced together (as
> > that would destroy information). So something along the lines of:
> >
> > 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
>
> Compared to v6.18-rc2, the output of "lspci -v" or "cat /proc/iomem"
> did not change. Hence for the two PCI/USB instances:
>
> 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
Hi Rob,
I'd want to hear your opinion on the solutions me and Geert tried and
discussed in the subthread starting from this:
https://lore.kernel.org/linux-pci/CAMuHMdVtVzcL3AX0uetNhKr-gLij37Ww+fcWXxnYpO3xRAOthA@mail.gmail.com/
A short history/summary of the problem and solution space:
I made "PCI: Resources outside their window must set IORESOURCE_UNSET"
change that checks at the init time whether BARs belong to an upstream
window or not. If not, the resource is marked wit IORESOURCE_UNSET to
indicate FW/platform didn't provide working addressing for those BARs.
On Geert's R-Car M2-W, it caused some BARs to be detected as not having a
an upstream window where they belong to:
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]
...In the log above, there's no root bus resource that covers
BAR0's 0xee090800-0xee090bff address range (which itself comes from DT
"reg"), and thus it got marked IORESOURCE_UNSET with as it does not
have window where it belongs to.
It's unclear to me whether DT ranges should have included BAR0 so that
the root bus resources would cover that range?
I was then told the updaing ranges now will not be enough due to DT
backwards compatibility requirements so it looks we have to resort to a
change like this:
https://lore.kernel.org/linux-pci/7640a03e-dfea-db9c-80f5-d80fa2c505b7@linux.intel.com/
(+ a few supporting changes as that change exposed brokenness in PCI core.)
Does that look correct solution? That is, should these be added on
case-by-case basis as additional root bus resources or should there be
something more generic in the OF PCI code to do it?
There's also that BAR1 which seems to be related to dma_ranges and I don't
know what to make of it. This resource comes with the added complication
that this same address appears more than once (in the full log there's
more than one PCI/USB instance). Again, this BAR1 is not covered by any
root bus resource and thus gets flagged with IORESOURCE_UNSET.
So I'm interested what is the "correct" solution for these resources that
appear as BARs but do not have a backing root bus resource, is it having
DT "ranges" cover them (I'm ignoring backwards compatibility aspect here)
or something else?
In addition, is there something special/non-ordinary with these BARs and
PCI core should treat them somehow differently? If that's the case, how
can I identify such BARs from "normal" ones to avoid messing with them?
--
i.
[+cc Marek, Yoshihiro for rcar-gen2]
On Wed, Oct 22, 2025 at 03:14:12PM +0300, Ilpo Järvinen wrote:
> On Wed, 22 Oct 2025, Geert Uytterhoeven wrote:
> > On Tue, 21 Oct 2025 at 13:54, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > On Tue, 21 Oct 2025, Geert Uytterhoeven wrote:
> > > > On Mon, 20 Oct 2025 at 18:20, Ilpo Järvinen
> > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > On Mon, 20 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > On Fri, 10 Oct 2025 at 16:42, Ilpo Järvinen
> > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > Here's a series for Geert to test if this fixes the improper coalescing
> > > > > > > of resources as was experienced with the pci_add_resource() change (I
> > > > > > > know the breaking change was pulled before 6.18 main PR but I'd want to
> > > > > > > retry it later once the known issues have been addressed). The expected
> > > > > > > result is there'll be two adjacent host bridge resources in the
> > > > > > > resource tree as the different name should disallow coalescing them
> > > > > > > together, and therefore BAR0 has a window into which it belongs to.
> > > > > > >
> > > > > > > Generic info for the series:
> > > > > > >
> > > > > > > PCI host bridge windows were coalesced in place into one of the structs
> > > > > > > on the resources list. The host bridge window coalescing code does not
> > > > > > > know who holds references and still needs the struct resource it's
> > > > > > > coalescing from/to so it is safer to perform coalescing into entirely
> > > > > > > a new struct resource instead and leave the old resource addresses as
> > > > > > > they were.
> > > > > > >
> > > > > > > The checks when coalescing is allowed are also made stricter so that
> > > > > > > only resources that have identical the metadata can be coalesced.
> > > > > > >
> > > > > > > As a bonus, there's also a bit of framework to easily create kunit
> > > > > > > tests for resource tree functions (beyond just resource_coalesce()).
> > > > > > >
> > > > > > > Ilpo Järvinen (3):
> > > > > > > PCI: Refactor host bridge window coalescing loop to use prev
> > > > > > > PCI: Do not coalesce host bridge resource structs in place
> > > > > > > resource, kunit: add test case for resource_coalesce()
> > > > > >
> > > > > > Thanks for your series!
> > > > > >
> > > > > > I have applied this on top of commit 06b77d5647a4d6a7 ("PCI:
> > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows"), and
> > > > > > gave it a a try on Koelsch (R-Car M2-W).
> > > > >
> > > > > So the pci_bus_add_resource() patch to rcar_pci_probe() was not included?
> > > > > No coalescing would be attempted without that change.
> > > >
> > > > Sorry, I didn't realize you wanted that (and anything else) to be
> > > > included, too. Please tell me the exact base I should use for testing,
> > > > and I will give it another run.
> > >
> > > I'm sorry, it's indeed a bit confusing as some of these patches never
> > > have been in Linus' tree.
> > >
> > > So I'm interested on what's the result with these changes/series together:
> > >
> > > [PATCH 1/2] PCI: Setup bridge resources earlier
> > > [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET
> > > [PATCH 1/1] PCI: rcar-gen2: Add BAR0 into host bridge resources
> > > [PATCH 1/3] PCI: Refactor host bridge window coalescing loop to use prev
> > > [PATCH 2/3] PCI: Do not coalesce host bridge resource structs in place
> > > [PATCH 3/3] resource, kunit: add test case for resource_coalesce()
> > >
> > > You might also want to change that pci_dbg() in the IORESOURCE_UNSET patch
> > > to pci_info() (as otherwise dyndbg is necessary to make it visible).
> >
> > Thanks, all done:
> >
> > $ git cherry -v --abbrev=1 v6.18-rc2^
> > + 211ddde0 Linux 6.18-rc2
> > + 3fdaf2 PCI: Setup bridge resources earlier
> > + 5be02e5 PCI: Resources outside their window must set IORESOURCE_UNSET
> > + adf6f11 PCI: rcar-gen2: Add BAR0 into host bridge resources
> > + eecb500 PCI: Refactor host bridge window coalescing loop to use prev
> > + 60470b3 PCI: Do not coalesce host bridge resource structs in place
> > + afe3ec resource, kunit: add test case for resource_coalesce()
> > + 487c98 Use dev_info() in drivers/pci/probe.c:__pci_read_base()
> > IORESOURCE_UNSET path
> >
> > Compared to v6.18-rc2, dmesg changed (for the first PCI/USB instance)
> > like:
> >
> > 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_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]
> > -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > +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_bus 0000:00: resource 5 [mem 0xee090000-0xee090bff]
> > pci 0000:00:01.0: enabling device (0140 -> 0142)
> > pci 0000:00:02.0: enabling device (0140 -> 0142)
> >
> > > The expected result is that those usb resources are properly parented and
> > > the ee080000-ee08ffff and ee090000-ee090bff are not coalesced together (as
> > > that would destroy information). So something along the lines of:
> > >
> > > 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
> >
> > Compared to v6.18-rc2, the output of "lspci -v" or "cat /proc/iomem"
> > did not change. Hence for the two PCI/USB instances:
> >
> > 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
>
> Hi Rob,
>
> I'd want to hear your opinion on the solutions me and Geert tried and
> discussed in the subthread starting from this:
>
> https://lore.kernel.org/linux-pci/CAMuHMdVtVzcL3AX0uetNhKr-gLij37Ww+fcWXxnYpO3xRAOthA@mail.gmail.com/
>
> A short history/summary of the problem and solution space:
>
> I made "PCI: Resources outside their window must set IORESOURCE_UNSET"
> change that checks at the init time whether BARs belong to an upstream
> window or not. If not, the resource is marked wit IORESOURCE_UNSET to
> indicate FW/platform didn't provide working addressing for those BARs.
>
> On Geert's R-Car M2-W, it caused some BARs to be detected as not having a
> an upstream window where they belong to:
>
> 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]
>
> ...In the log above, there's no root bus resource that covers
> BAR0's 0xee090800-0xee090bff address range (which itself comes from DT
> "reg"), and thus it got marked IORESOURCE_UNSET with as it does not
> have window where it belongs to.
I guess this came from arch/arm/boot/dts/renesas/r8a7791.dtsi:
pci0: pci@ee090000 {
compatible = "renesas,pci-r8a7791",
"renesas,pci-rcar-gen2";
reg = <0 0xee090000 0 0xc00>,
<0 0xee080000 0 0x1100>;
ranges = <0x02000000 0 0xee080000 0 0xee080000 0 0x00010000>;
bus-range = <0 0>;
pciec: pcie@fe000000 {
compatible = "renesas,pcie-r8a7791",
"renesas,pcie-rcar-gen2";
dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000>,
bus-range = <0x00 0xff>;
"reg" describes address space on a device's parent side, e.g.,
memory-mapped registers consumed by the device itself. Since this is
a host bridge, it also has "ranges" to describe address space on its
child side, including any address translation from the parent side.
PCI devices are on the child side and should consume space from the
"ranges" child side, [mem 0xee080000-0xee08ffff] in this case.
00:00.0: BAR 0 [mem 0xee090800-0xee090bff] isn't in that child address
space so I think it's invalid per spec. Does 00:00.0 actually respond
at whatever address is in BAR 0? Do we care? I don't see any driver
that claims [1033:0000].
00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref] looks like it came
from the pcie@fe000000 "dma-ranges", which describes valid child
address space for DMA. We need to know the DMA address space, of
course, but we get it from "dma-ranges", not from a BAR.
I think it would be nicest if pci-rcar-gen2.c could hide both BAR 0
and 1 somehow so they wouldn't confuse us.
(BTW, I don't understand how both pci@ee090000 and pcie@fe000000 say
they are bridges to bus 0.)
> It's unclear to me whether DT ranges should have included BAR0 so that
> the root bus resources would cover that range?
>
> I was then told the updating ranges now will not be enough due to DT
> backwards compatibility requirements so it looks we have to resort to a
> change like this:
>
> https://lore.kernel.org/linux-pci/7640a03e-dfea-db9c-80f5-d80fa2c505b7@linux.intel.com/
>
> (+ a few supporting changes as that change exposed brokenness in PCI core.)
>
> Does that look correct solution? That is, should these be added on
> case-by-case basis as additional root bus resources or should there be
> something more generic in the OF PCI code to do it?
>
> There's also that BAR1 which seems to be related to dma_ranges and I don't
> know what to make of it. This resource comes with the added complication
> that this same address appears more than once (in the full log there's
> more than one PCI/USB instance). Again, this BAR1 is not covered by any
> root bus resource and thus gets flagged with IORESOURCE_UNSET.
>
> So I'm interested what is the "correct" solution for these resources that
> appear as BARs but do not have a backing root bus resource, is it having
> DT "ranges" cover them (I'm ignoring backwards compatibility aspect here)
> or something else?
>
>
> In addition, is there something special/non-ordinary with these BARs and
> PCI core should treat them somehow differently? If that's the case, how
> can I identify such BARs from "normal" ones to avoid messing with them?
>
>
> --
> i.
On Wed, Oct 22, 2025 at 03:14:12PM +0300, Ilpo Järvinen wrote:
> On Wed, 22 Oct 2025, Geert Uytterhoeven wrote:
> > On Tue, 21 Oct 2025 at 13:54, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > On Tue, 21 Oct 2025, Geert Uytterhoeven wrote:
> > > > On Mon, 20 Oct 2025 at 18:20, Ilpo Järvinen
> > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > On Mon, 20 Oct 2025, Geert Uytterhoeven wrote:
> > > > > > On Fri, 10 Oct 2025 at 16:42, Ilpo Järvinen
> > > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > > Here's a series for Geert to test if this fixes the improper coalescing
> > > > > > > of resources as was experienced with the pci_add_resource() change (I
> > > > > > > know the breaking change was pulled before 6.18 main PR but I'd want to
> > > > > > > retry it later once the known issues have been addressed). The expected
> > > > > > > result is there'll be two adjacent host bridge resources in the
> > > > > > > resource tree as the different name should disallow coalescing them
> > > > > > > together, and therefore BAR0 has a window into which it belongs to.
> > > > > > >
> > > > > > > Generic info for the series:
> > > > > > >
> > > > > > > PCI host bridge windows were coalesced in place into one of the structs
> > > > > > > on the resources list. The host bridge window coalescing code does not
> > > > > > > know who holds references and still needs the struct resource it's
> > > > > > > coalescing from/to so it is safer to perform coalescing into entirely
> > > > > > > a new struct resource instead and leave the old resource addresses as
> > > > > > > they were.
> > > > > > >
> > > > > > > The checks when coalescing is allowed are also made stricter so that
> > > > > > > only resources that have identical the metadata can be coalesced.
> > > > > > >
> > > > > > > As a bonus, there's also a bit of framework to easily create kunit
> > > > > > > tests for resource tree functions (beyond just resource_coalesce()).
> > > > > > >
> > > > > > > Ilpo Järvinen (3):
> > > > > > > PCI: Refactor host bridge window coalescing loop to use prev
> > > > > > > PCI: Do not coalesce host bridge resource structs in place
> > > > > > > resource, kunit: add test case for resource_coalesce()
> > > > > >
> > > > > > Thanks for your series!
> > > > > >
> > > > > > I have applied this on top of commit 06b77d5647a4d6a7 ("PCI:
> > > > > > Mark resources IORESOURCE_UNSET when outside bridge windows"), and
> > > > > > gave it a a try on Koelsch (R-Car M2-W).
> > > > >
> > > > > So the pci_bus_add_resource() patch to rcar_pci_probe() was not included?
> > > > > No coalescing would be attempted without that change.
> > > >
> > > > Sorry, I didn't realize you wanted that (and anything else) to be
> > > > included, too. Please tell me the exact base I should use for testing,
> > > > and I will give it another run.
> > >
> > > I'm sorry, it's indeed a bit confusing as some of these patches never
> > > have been in Linus' tree.
> > >
> > > So I'm interested on what's the result with these changes/series together:
> > >
> > > [PATCH 1/2] PCI: Setup bridge resources earlier
> > > [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET
> > > [PATCH 1/1] PCI: rcar-gen2: Add BAR0 into host bridge resources
> > > [PATCH 1/3] PCI: Refactor host bridge window coalescing loop to use prev
> > > [PATCH 2/3] PCI: Do not coalesce host bridge resource structs in place
> > > [PATCH 3/3] resource, kunit: add test case for resource_coalesce()
> > >
> > > You might also want to change that pci_dbg() in the IORESOURCE_UNSET patch
> > > to pci_info() (as otherwise dyndbg is necessary to make it visible).
> >
> > Thanks, all done:
> >
> > $ git cherry -v --abbrev=1 v6.18-rc2^
> > + 211ddde0 Linux 6.18-rc2
> > + 3fdaf2 PCI: Setup bridge resources earlier
> > + 5be02e5 PCI: Resources outside their window must set IORESOURCE_UNSET
> > + adf6f11 PCI: rcar-gen2: Add BAR0 into host bridge resources
> > + eecb500 PCI: Refactor host bridge window coalescing loop to use prev
> > + 60470b3 PCI: Do not coalesce host bridge resource structs in place
> > + afe3ec resource, kunit: add test case for resource_coalesce()
> > + 487c98 Use dev_info() in drivers/pci/probe.c:__pci_read_base()
> > IORESOURCE_UNSET path
> >
> > Compared to v6.18-rc2, dmesg changed (for the first PCI/USB instance)
> > like:
> >
> > 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_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]
> > -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> > +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_bus 0000:00: resource 5 [mem 0xee090000-0xee090bff]
> > pci 0000:00:01.0: enabling device (0140 -> 0142)
> > pci 0000:00:02.0: enabling device (0140 -> 0142)
> >
> > > The expected result is that those usb resources are properly parented and
> > > the ee080000-ee08ffff and ee090000-ee090bff are not coalesced together (as
> > > that would destroy information). So something along the lines of:
> > >
> > > 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
> >
> > Compared to v6.18-rc2, the output of "lspci -v" or "cat /proc/iomem"
> > did not change. Hence for the two PCI/USB instances:
> >
> > 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
>
> Hi Rob,
>
> I'd want to hear your opinion on the solutions me and Geert tried and
> discussed in the subthread starting from this:
>
> https://lore.kernel.org/linux-pci/CAMuHMdVtVzcL3AX0uetNhKr-gLij37Ww+fcWXxnYpO3xRAOthA@mail.gmail.com/
>
> A short history/summary of the problem and solution space:
>
> I made "PCI: Resources outside their window must set IORESOURCE_UNSET"
> change that checks at the init time whether BARs belong to an upstream
> window or not. If not, the resource is marked wit IORESOURCE_UNSET to
> indicate FW/platform didn't provide working addressing for those BARs.
>
> On Geert's R-Car M2-W, it caused some BARs to be detected as not having a
> an upstream window where they belong to:
>
> 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]
>
> ...In the log above, there's no root bus resource that covers
> BAR0's 0xee090800-0xee090bff address range (which itself comes from DT
> "reg"), and thus it got marked IORESOURCE_UNSET with as it does not
> have window where it belongs to.
>
> It's unclear to me whether DT ranges should have included BAR0 so that
> the root bus resources would cover that range?
I think it should. Otherwise, how do you know if the region is 32 or 64
bit or prefetchable or not?
>
> I was then told the updaing ranges now will not be enough due to DT
> backwards compatibility requirements so it looks we have to resort to a
> change like this:
>
> https://lore.kernel.org/linux-pci/7640a03e-dfea-db9c-80f5-d80fa2c505b7@linux.intel.com/
You aren't adding 'BAR0 region', but something else. Based on the name,
cfg_res, that is config space? That seems wrong both in requiring it to
be registered and that you would assign BAR0 to config space. How would
that device operate when config space is not memory mapped?
For compatibility, the change itself doesn't look so bad. However, we
could also fixup the DT itself. That's not done too much on Arm systems,
but there's all sorts of fixups in powerpc. I have some initial
infrastructure to support that if we need to go down that path.
>
> (+ a few supporting changes as that change exposed brokenness in PCI core.)
>
> Does that look correct solution? That is, should these be added on
> case-by-case basis as additional root bus resources or should there be
> something more generic in the OF PCI code to do it?
>
> There's also that BAR1 which seems to be related to dma_ranges and I don't
> know what to make of it. This resource comes with the added complication
> that this same address appears more than once (in the full log there's
> more than one PCI/USB instance). Again, this BAR1 is not covered by any
> root bus resource and thus gets flagged with IORESOURCE_UNSET.
>
> So I'm interested what is the "correct" solution for these resources that
> appear as BARs but do not have a backing root bus resource, is it having
> DT "ranges" cover them (I'm ignoring backwards compatibility aspect here)
> or something else?
If it is config space, no, I don't think ranges should cover that.
'ranges' should have all the memory and io spaces.
> In addition, is there something special/non-ordinary with these BARs and
> PCI core should treat them somehow differently? If that's the case, how
> can I identify such BARs from "normal" ones to avoid messing with them?
You've exceeded my PCI knowledge on this...
Rob
On Wed, 22 Oct 2025, Geert Uytterhoeven wrote:
> On Tue, 21 Oct 2025 at 13:54, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Tue, 21 Oct 2025, Geert Uytterhoeven wrote:
> > > On Mon, 20 Oct 2025 at 18:20, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > On Mon, 20 Oct 2025, Geert Uytterhoeven wrote:
> > > > > On Fri, 10 Oct 2025 at 16:42, Ilpo Järvinen
> > > > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > > > Here's a series for Geert to test if this fixes the improper coalescing
> > > > > > of resources as was experienced with the pci_add_resource() change (I
> > > > > > know the breaking change was pulled before 6.18 main PR but I'd want to
> > > > > > retry it later once the known issues have been addressed). The expected
> > > > > > result is there'll be two adjacent host bridge resources in the
> > > > > > resource tree as the different name should disallow coalescing them
> > > > > > together, and therefore BAR0 has a window into which it belongs to.
> > > > > >
> > > > > > Generic info for the series:
> > > > > >
> > > > > > PCI host bridge windows were coalesced in place into one of the structs
> > > > > > on the resources list. The host bridge window coalescing code does not
> > > > > > know who holds references and still needs the struct resource it's
> > > > > > coalescing from/to so it is safer to perform coalescing into entirely
> > > > > > a new struct resource instead and leave the old resource addresses as
> > > > > > they were.
> > > > > >
> > > > > > The checks when coalescing is allowed are also made stricter so that
> > > > > > only resources that have identical the metadata can be coalesced.
> > > > > >
> > > > > > As a bonus, there's also a bit of framework to easily create kunit
> > > > > > tests for resource tree functions (beyond just resource_coalesce()).
> > > > > >
> > > > > > Ilpo Järvinen (3):
> > > > > > PCI: Refactor host bridge window coalescing loop to use prev
> > > > > > PCI: Do not coalesce host bridge resource structs in place
> > > > > > resource, kunit: add test case for resource_coalesce()
> > > > >
> > > > > Thanks for your series!
> > > > >
> > > > > I have applied this on top of commit 06b77d5647a4d6a7 ("PCI:
> > > > > Mark resources IORESOURCE_UNSET when outside bridge windows"), and
> > > > > gave it a a try on Koelsch (R-Car M2-W).
> > > >
> > > > So the pci_bus_add_resource() patch to rcar_pci_probe() was not included?
> > > > No coalescing would be attempted without that change.
> > >
> > > Sorry, I didn't realize you wanted that (and anything else) to be
> > > included, too. Please tell me the exact base I should use for testing,
> > > and I will give it another run.
> >
> > I'm sorry, it's indeed a bit confusing as some of these patches never
> > have been in Linus' tree.
> >
> > So I'm interested on what's the result with these changes/series together:
> >
> > [PATCH 1/2] PCI: Setup bridge resources earlier
> > [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET
> > [PATCH 1/1] PCI: rcar-gen2: Add BAR0 into host bridge resources
> > [PATCH 1/3] PCI: Refactor host bridge window coalescing loop to use prev
> > [PATCH 2/3] PCI: Do not coalesce host bridge resource structs in place
> > [PATCH 3/3] resource, kunit: add test case for resource_coalesce()
> >
> > You might also want to change that pci_dbg() in the IORESOURCE_UNSET patch
> > to pci_info() (as otherwise dyndbg is necessary to make it visible).
>
> Thanks, all done:
>
> $ git cherry -v --abbrev=1 v6.18-rc2^
> + 211ddde0 Linux 6.18-rc2
> + 3fdaf2 PCI: Setup bridge resources earlier
> + 5be02e5 PCI: Resources outside their window must set IORESOURCE_UNSET
> + adf6f11 PCI: rcar-gen2: Add BAR0 into host bridge resources
> + eecb500 PCI: Refactor host bridge window coalescing loop to use prev
> + 60470b3 PCI: Do not coalesce host bridge resource structs in place
> + afe3ec resource, kunit: add test case for resource_coalesce()
> + 487c98 Use dev_info() in drivers/pci/probe.c:__pci_read_base()
> IORESOURCE_UNSET path
>
> Compared to v6.18-rc2, dmesg changed (for the first PCI/USB instance)
> like:
>
> 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_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]
> -pci 0000:00:00.0: BAR 1 [mem 0x40000000-0x7fffffff pref]
> +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_bus 0000:00: resource 5 [mem 0xee090000-0xee090bff]
> pci 0000:00:01.0: enabling device (0140 -> 0142)
> pci 0000:00:02.0: enabling device (0140 -> 0142)
>
> > The expected result is that those usb resources are properly parented and
> > the ee080000-ee08ffff and ee090000-ee090bff are not coalesced together (as
> > that would destroy information). So something along the lines of:
> >
> > 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
>
> Compared to v6.18-rc2, the output of "lspci -v" or "cat /proc/iomem"
> did not change. Hence for the two PCI/USB instances:
>
> 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
Looks it works now when it comes to what PCI: Resources outside their
window must set IORESOURCE_UNSET tried to achieve.
Thanks a lot for all the testing!
--
i.
On Tue, Oct 21, 2025 at 02:54:03PM +0300, Ilpo Järvinen wrote: > On Tue, 21 Oct 2025, Geert Uytterhoeven wrote: ... > I'm sorry, it's indeed a bit confusing as some of these patches never > have been in Linus' tree. > > So I'm interested on what's the result with these changes/series together: > > [PATCH 1/2] PCI: Setup bridge resources earlier > [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET > [PATCH 1/1] PCI: rcar-gen2: Add BAR0 into host bridge resources > [PATCH 1/3] PCI: Refactor host bridge window coalescing loop to use prev > [PATCH 2/3] PCI: Do not coalesce host bridge resource structs in place > [PATCH 3/3] resource, kunit: add test case for resource_coalesce() > > You might also want to change that pci_dbg() in the IORESOURCE_UNSET patch > to pci_info() (as otherwise dyndbg is necessary to make it visible). > > Lore links to these series/patches: > > https://lore.kernel.org/linux-pci/20250924134228.1663-1-ilpo.jarvinen@linux.intel.com/ > https://lore.kernel.org/linux-pci/7640a03e-dfea-db9c-80f5-d80fa2c505b7@linux.intel.com/ > https://lore.kernel.org/linux-pci/20251010144231.15773-1-ilpo.jarvinen@linux.intel.com/ > > The expected result is that those usb resources are properly parented and > the ee080000-ee08ffff and ee090000-ee090bff are not coalesced together (as > that would destroy information). So something along the lines of: > > ee080000-ee08ffff : pci@ee090000 For my pedantic eye, the naming is a bit confusing here. Is this a mistake in the code or in the example? > 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 -- With Best Regards, Andy Shevchenko
Hi Andy,
On Tue, 21 Oct 2025 at 17:49, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Tue, Oct 21, 2025 at 02:54:03PM +0300, Ilpo Järvinen wrote:
> > The expected result is that those usb resources are properly parented and
> > the ee080000-ee08ffff and ee090000-ee090bff are not coalesced together (as
> > that would destroy information). So something along the lines of:
> >
> > ee080000-ee08ffff : pci@ee090000
>
> For my pedantic eye, the naming is a bit confusing here. Is this a mistake in
> the code or in the example?
>
> > 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
A platform device instantiated from DT is named after the node name
and unit address of the corresponding DT node. If the device has
multiple register banks, all its register banks are still claimed by
the same device, so all but the first (in DT) register bank show a
non-matching address in the device name.
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, 21 Oct 2025, Andy Shevchenko wrote: > On Tue, Oct 21, 2025 at 02:54:03PM +0300, Ilpo Järvinen wrote: > > On Tue, 21 Oct 2025, Geert Uytterhoeven wrote: > > ... > > > I'm sorry, it's indeed a bit confusing as some of these patches never > > have been in Linus' tree. > > > > So I'm interested on what's the result with these changes/series together: > > > > [PATCH 1/2] PCI: Setup bridge resources earlier > > [PATCH 2/2] PCI: Resources outside their window must set IORESOURCE_UNSET > > [PATCH 1/1] PCI: rcar-gen2: Add BAR0 into host bridge resources > > [PATCH 1/3] PCI: Refactor host bridge window coalescing loop to use prev > > [PATCH 2/3] PCI: Do not coalesce host bridge resource structs in place > > [PATCH 3/3] resource, kunit: add test case for resource_coalesce() > > > > You might also want to change that pci_dbg() in the IORESOURCE_UNSET patch > > to pci_info() (as otherwise dyndbg is necessary to make it visible). > > > > Lore links to these series/patches: > > > > https://lore.kernel.org/linux-pci/20250924134228.1663-1-ilpo.jarvinen@linux.intel.com/ > > https://lore.kernel.org/linux-pci/7640a03e-dfea-db9c-80f5-d80fa2c505b7@linux.intel.com/ > > https://lore.kernel.org/linux-pci/20251010144231.15773-1-ilpo.jarvinen@linux.intel.com/ > > > > The expected result is that those usb resources are properly parented and > > the ee080000-ee08ffff and ee090000-ee090bff are not coalesced together (as > > that would destroy information). So something along the lines of: > > > > ee080000-ee08ffff : pci@ee090000 > > For my pedantic eye, the naming is a bit confusing here. Is this a mistake in > the code or in the example? > > > 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 I tried to copy them from here: https://lore.kernel.org/linux-pci/CAMuHMdUbaQDXsowZETimLJ-=gLCofeP+LnJp_txetuBQ0hmcPQ@mail.gmail.com/ So my answer is, from code. I'm not trying to change the names here, they are what they are. Why things work that way in DT platform (ee08 vs @ee09), don't ask me as I unfortunately don't know the answers. -- i.
© 2016 - 2025 Red Hat, Inc.