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.