[RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
From: Alexander Holler <hidden>
Date: 2014-08-26 11:01:53
Also in:
linux-devicetree, lkml
Am 26.08.2014 12:44, schrieb Alexander Holler:
Am 26.08.2014 12:25, schrieb Thierry Reding:quoted
On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote:quoted
quoted
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.That would end up with almost the same ugly driver-based workarounds as now. It's much better if a driver author only has to define it's prerequisits (in form of dependencies in the dts) and could be sure the driver will only be probed if those are met, than to do that stuff based on a subsystem or even driver level. If you add dependency-information to drivers, you have two problems: - How do you get these information from the driver (remember, currently there is only one initial call, a initcall which might do almost anything) - These information might become outdated and you would have to change all drivers. E.g. if the name of a dependency (driver) changes it wouldn't be done with changing the dts (maybe plural), but you would have to change the source of all dependant drivers too.
And after having sorted my brain: A driver depends on a binding (and its API), but not on explicit named other drivers. So trying it (again) on driver level is doomed to fail. Alexander Holler