On 08/22/2018 08:08 PM, Simon Glass wrote: [...] >> This is explained in the patch description and the thread again. Please >> read the thread before replying. Take a look at the r8a7794.dtsi and its >> PCI bindings, there are PCI controller subnodes which add extra >> information for PCI devices on the bus. These nodes do not have a >> compatible string, only a BFD. >> >> This is perfectly valid, since you can match a driver on the PCI IDs or >> classes (PCI_DEVICE()), but the driver doesn't have a DT node associated >> with it. If there is a DT node with a matching BFD, it is associated >> with the driver instance by this patch. >> >> This allows ie. the EHCI PCI driver to access that DT node and extract >> information about PHYs from the DT (in case of the r8a7794). > > But the code to do this already exists in pci_bind_bus_devices(). > > I know I am late to this thread but no one is going to read 45 messages, > sorry.
But then what is the point of having ML discussions archived at all if I have to explain the same thing over and over to everyone who comes into the thread ? > Why is pci_bus_find_devfn() failing? Because this function is a hack to force-bind drivers to PCI devices which are described in the DT with a compatible string. This does not apply to this case. If this function fails (correctly, no force-binding needs to happen because there is no compatible string, we want to match on PCI IDs), the code will continue and match on PCI ID/class with pci_find_and_bind_driver() . That function is where we need to verify if there isn't a PCI controller subnode in DT with a matching BFD which should be associated with the new driver instance. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
