[RFC PATCH 2/9] dt: deps: dependency based device creation

[Alexander Holler]

Am 14.05.2014 16:49, schrieb Alexander Holler:
> Am 14.05.2014 16:05, schrieb Grant Likely:
>> On Mon, 12 May 2014 18:47:53 +0200, Alexander Holler
>> <holler at ahsoftware.de> wrote:

>> Personally, I think the parts of this patch that manipulate the device
>> registration
>> order is entirely the wrong way to handle it. If anything, I would say
>> continue to register the devices, even if the dependencies are unmet.

(...)

>> How does the dependency code decide which devices can be
>> platform_devices? It's not clear to me from what I've read so far.
>
> Dependencies currently are only considered on stuff which has a
> "compatibility" property, thus drivers. I wanted to get the drivers
> loaded in order, not really caring for devices. Let me quote from
> (outdated) ldd3:
>
> "For the most part, the Linux device model code takes care of all these
> considerations without imposing itself upon driver authors. It sits
> mostly in the background; direct interaction with the device model is
> generally handled by bus-level logic and various other kernel
> subsystems. As a result, many driver authors can ignore the device model
> entirely, and trust it to take care of itself."
>
> So do I. ;)

To explain a bit further, I've started with totally ignoring the device 
model just careing for the order in why drivers will be initialized.

Than the device model did come into my way. ;)

But it isn't any problem at all to extend the stuff to care for devices. 
That even  would reduce some code in dtc with the disadvantage that the 
sizes of blobs will slightly increase a bit more, because they then 
would include dependencies to devices too (instead of just dependencies 
between drivers).

So I'm absolutely open here. If using dependencies between devices is 
necessary or has advantages, that could be changed with changing a few 
lines.

Regards,

Alexander Holler