linux-kernel - Re: [RFC PATCH 2/9] dt: deps: dependency based device creation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 May 2014 19:20:21 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Grant Likely <grant.likely@...aro.org>,
	linux-kernel@...r.kernel.org
CC:	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Russell King <linux@....linux.org.uk>,
	Jon Loeliger <jdl@....com>, Rob Herring <robh+dt@...nel.org>
Subject: Re: [RFC PATCH 2/9] dt: deps: dependency based device creation

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@...oftware.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/