linux-kernel - Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <53FC6513.5040800@ahsoftware.de>
Date:	Tue, 26 Aug 2014 12:44:35 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Thierry Reding <thierry.reding@...il.com>
CC:	Grant Likely <grant.likely@...aro.org>, Jon Loeliger <jdl@....com>,
	Mark Rutland <mark.rutland@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Rob Herring <robh+dt@...nel.org>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization
 order based on the DT)

Am 26.08.2014 12:25, schrieb Thierry Reding:
> On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote:

>> 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.

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/