On Thu, Apr 11, 2024 at 07:39:17AM -0500, Bjorn Helgaas wrote: > On Thu, Apr 11, 2024 at 08:13:18AM +0200, Sergio Paracuellos wrote: > > On Thu, Apr 11, 2024 at 8:01 AM Krzysztof Kozlowski > > <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > > On 10/04/2024 23:26, Bjorn Helgaas wrote: > > > > On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote: > > > >> MT7621 PCI host bridge has children which apparently are also PCI host > > > >> bridges, at least that's what the binding suggest. > > > > > > > > What does it even mean for a PCI host bridge to have a child that is > > > > also a PCI host bridge? It should say 'root port' instead as the binding description correctly says. > > > > > > > > Does this mean a driver binds to the "parent" host bridge, enumerates > > > > the PCI devices below it, and finds a "child" host bridge? > > > > Yes, that is exactly what you can see on enumeration. > > > > The following is a typical boot trace where all bridges has a device also below: > > > > mt7621-pci 1e140000.pcie: host bridge /pcie@1e140000 ranges: > > mt7621-pci 1e140000.pcie: No bus range found for /pcie@1e140000, using [bus 00-ff] > > mt7621-pci 1e140000.pcie: MEM 0x0060000000..0x006fffffff -> 0x0060000000 > > mt7621-pci 1e140000.pcie: IO 0x001e160000..0x001e16ffff -> 0x0000000000 > > mt7621-pci 1e140000.pcie: PCIE0 enabled > > mt7621-pci 1e140000.pcie: PCIE1 enabled > > mt7621-pci 1e140000.pcie: PCIE2 enabled > > mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00 > > 1e140000.pcie is a host bridge. It has some CPU-specific bus on the > upstream side, standard PCI (domain 0000, buses 00-ff) on the > downstream side. > > > pci 0000:00:00.0: [0e8d:0801] type 01 class 0x060400 > > pci 0000:00:01.0: [0e8d:0801] type 01 class 0x060400 > > pci 0000:00:02.0: [0e8d:0801] type 01 class 0x060400 > > > pci 0000:01:00.0: [1b21:0611] type 00 class 0x010185 > > > pci 0000:00:00.0: PCI bridge to [bus 01-ff] > > pci 0000:00:00.0: bridge window [io 0x0000-0x0fff] > > pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] > > pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff pref] > > 00:00.0 looks like a PCIe Root Port to bus 01. This is not a host > bridge; it's just a standard PCI-to-PCI bridge with PCI on both the > upstream and downstream sides. > > > pci 0000:02:00.0: [1b21:0611] type 00 class 0x010185 > > > pci 0000:00:01.0: PCI bridge to [bus 02-ff] > > pci 0000:00:01.0: bridge window [io 0x0000-0x0fff] > > pci 0000:00:01.0: bridge window [mem 0x00000000-0x000fffff] > > pci 0000:00:01.0: bridge window [mem 0x00000000-0x000fffff pref] > > 00:01.0 is another Root Port to bus 02. > > > pci 0000:03:00.0: [1b21:0611] type 00 class 0x010185 > > > pci 0000:00:02.0: PCI bridge to [bus 03-ff] > > pci 0000:00:02.0: bridge window [io 0x0000-0x0fff] > > pci 0000:00:02.0: bridge window [mem 0x00000000-0x000fffff] > > pci 0000:00:02.0: bridge window [mem 0x00000000-0x000fffff pref] > > pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03 > > And 00:02.0 is a third Root Port to bus 03. > > > pci 0000:00:00.0: PCI bridge to [bus 01] > > pci 0000:00:00.0: bridge window [io 0x0000-0x0fff] > > pci 0000:00:00.0: bridge window [mem 0x60000000-0x600fffff] > > pci 0000:00:00.0: bridge window [mem 0x60100000-0x601fffff pref] > > pci 0000:00:01.0: PCI bridge to [bus 02] > > pci 0000:00:01.0: bridge window [io 0x1000-0x1fff] > > pci 0000:00:01.0: bridge window [mem 0x60200000-0x602fffff] > > pci 0000:00:01.0: bridge window [mem 0x60300000-0x603fffff pref] > > pci 0000:00:02.0: PCI bridge to [bus 03] > > pci 0000:00:02.0: bridge window [io 0x2000-0x2fff] > > pci 0000:00:02.0: bridge window [mem 0x60400000-0x604fffff] > > > > > I think the question should be towards Mediatek folks. I don't know what > > > this hardware is exactly, just looks like pci-pci-bridge. The driver > > > calls the children host bridges as "ports". > > > > You can see the topology here in my first driver submit cover letter > > message [0]. > > > > [0]: https://lore.kernel.org/all/CAMhs-H-BA+KzEwuDPzcmrDPdgJBFA2XdYTBvT4R4MEOUB=WQ1g@xxxxxxxxxxxxxx/t/ > > Nothing unusual here, this looks like the standard PCIe topology. > > What *might* be unusual is describing the Root Ports in DT. Since > they are standard PCI devices, they shouldn't need DT description > unless there's some unusual power/clock/reset control or something > that is not discoverable via PCI enumeration. It's only unusual because typically there's only 1 RP per host bridge and properties which really apply to the RP get stuck in the host bridge node because we don't have a RP node. An example is perst-gpios. That's not a property of the RP either, but the RP is the upstream side of a slot and we often don't have a node for the device either. Rob
