On Wed, Apr 06, 2022 at 09:52:13AM +0200, Clément Léger wrote: > Le Tue, 5 Apr 2022 16:28:02 -0500, > Rob Herring <robh@xxxxxxxxxx> a écrit : > > > > > > > > No, the kernel already maintains its own tree of devices. You just > > > need to use that to generate the tree. That's really not much more > > > than nodes with a 'reg' property encoding the device and function > > > numbers. > > > > > > We already support matching a PCI device to a DT node. The PCI > > > subsystem checks if there is a corresponding DT node for each PCI > > > device created and sets the of_node pointer if there is. For > > > OpenFirmware systems (PPC), there always is a node. For FDT, we > > > generally don't have a node unless there are additional > > > non-discoverable properties. Hikey960 is an example with PCI device > > > nodes in the DT as it has a soldered down PCIe switch with downstream > > > devices and non-discoverable properties (e.g. reset GPIO for each > > > port). > > > > Here's a quick and dirty implementation creating DT nodes for PCI devices: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dt/pop-pci-nodes > > Ok, thanks, after looking at the branch, it appears that you expect the > PCI nodes matching the probed PCI devices should be created by the PCI > subsystem itself. My previous comment saying that the node would be > created by the PCI driver itself is then wrong and I understand what > you meant. As I said before, the driver could create its node and all the parents. I went with the other option partly because I didn't have a particular driver. That has the advantage of only creating necessary nodes and provides a way to trigger doing so. The issue with it is the timing of when the node gets set (after parent devices have probed). > Then, there is still a bit of magic to do to correctly fill the ranges > for translation and then the driver "simply" have to load the dtbo and > apply it with of_overlay_fdt_apply(). The host bridge resource list should have all the information needed. Rob
