On Wednesday 27 October 2021 11:58:57 Bjorn Helgaas wrote: > On Tue, Oct 26, 2021 at 05:27:32PM -0400, Jim Quinlan wrote: > > > I don't think it matters but our PCIe controllers only have a single > > root port. > > Just to kibitz, and I don't know anything about the DT binding under > discussion here, but I would prefer if DTs and drivers did not have > the "single root port" assumption baked deeply in them. +1 Please look also at my proposal for similar/same issue: https://lore.kernel.org/linux-pci/20211023144252.z7ou2l2tvm6cvtf7@pali/t/#u > I expect some controllers to support multiple root ports, and it would > be really nice if the DTs and drivers all had similar structures with > the single-root-port controllers just being the N=1 case. > > For example, some drivers put their per-root port stuff in > *_add_pcie_port() functions, which I think is a nice way to do it > because it leaves the door open for calling *_add_pcie_port() in a > loop. > > Ironically, the only driver I see that looks like it currently > supports multiple root ports is pci-mvebu.c, and it doesn't have an > _add_pcie_port() function. Ironically, pci-mvebu.c is doing it wrong because HW has basically N fully independent HW host bridges and pci-mvebu.c driver is registering one kernel virtual host bridge device and is merging root ports of all host bridges into this one "virtual" bus which belongs to that kernel virtual host bridge... Plus root ports are also "virtual" because they are broken in HW. So correctly pci-mvebu.c should have been split into separate host bridge DTS nodes, but due to backward compatibility it is not possible. > Having this sort of consistent structure and naming across drivers is > a huge help for ongoing maintenance. > > Bjorn +1 That is why I sent that my proposal. Defining this as a common way for (new) drivers would really helps a lot all maintenance.
