On Fri, Jul 5, 2013 at 9:50 AM, Russell King <rmk@xxxxxxxxxxxxxxxx> wrote: > On Fri, Jul 05, 2013 at 09:37:34AM +0100, Grant Likely wrote: >> Alternatively, you can have the same effect with a property or set of >> properties in the controller node that contains phandles to the >> required devices. That would provide the driver with the same >> information about which devices must be present. > > How do you go from phandle to something-that-the-driver-for-that-device- > has-setup? > > From what I can see, you can go from phandle to OF node, but no further. Correct, and that has historically been by design because it is possible for multiple struct devices to reference a single device_node. Any subsystem that needs to get a particular device has a lookup mechanism that searches the list of known devices and returns a match. example: of_mdio_find_bus() > I'm guessing we'd need some kind of "registry" for sub-drivers with > these structures to register their devices OF node plus "shared" data > so that other drivers can find it. "shared" data might be a > standardized operations struct or something similar to 'struct > device_driver' but for componentised devices. If it is per-subsystem, the effort shouldn't be too high because it will be able to collect devices of the same type. It gets more complicated to design a generic componentised device abstraction (which I'm not opposed to, it's just going to be tricky and subtle). One big concern I have is differentiating between manditory and optional dependencies. Manditory is always easy to handle, but what about cases where the supernode (using phandles to other nodes) references other devices, but it is perfectly valid for the driver to complete probing before it becomes available? I may just be borrowing trouble here though. Supporting only mandatory dependencies in the first cut would still be a big step forward. One simple approach would be to add a "depends on" list to struct device and make the driver core check that all the dependant devices have drivers before probing. The risk is that would become a complicated set of reference counting and housekeeping. g. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
