On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote: > Am 26.08.2014 10:49, schrieb Thierry Reding: > >On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote: > >>On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > >[...] > >>>There are somewhat standardized bindings for the above and especially > >>>for bindings of the type that clocks implement this is trivial. We can > >>>simply iterate over each (phandle, specifier) tuple and check that the > >>>corresponding clock provider can be resolved (which typically means that > >>>it's been registered with the common clock framework). > >>> > >>>For regulators (and regulator-like bindings) the problem is somewhat > >>>more difficult because they property names are not standardized. One way > >>>to solve this would be to look for property names with a -supply suffix, > >>>but that could obviously lead to false positives. One alternative that I > >>>think could eliminate this would be to explicitly list dependencies in > >>>drivers. This would allow core code to step through such a list and > >>>resolve the (phandle, specifier) tuples. > >> > >>False positives and negatives may not actually be a problem. It is > >>suboptimal, certainly, but it shouldn't outright break the kernel. > > > >There could be cases where some random integer in a cell could be > >interpreted as a phandle and resolve to a struct device_node. I suppose > >it might be unlikely, but not impossible, that the device_node could > >even match a device in the correct subsystem and you'd get a wrong > >dependency. Granted, a wrong dependency may not be catastrophic in that > >it won't lead to a crash, but it could lead to various kinds of > >weirdness and hard to diagnose problems. > > You need either the type information in the DTB (that's why I've add those > "dependencies" to identify phandles), or you need to know every binding (at > "dependency-resolve-time" to identify phandles. The latter is impracticable > to implement in a generic way (for use with every possible binding). Like I already mentioned, this could be done in drivers who contain that information already anyway. Or parts of it could be done in subsystem- specific callbacks where a generic binding is available. Thierry
Attachment:
pgphsd7sG3X9m.pgp
Description: PGP signature
