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: <20140827103432.64927C409CB@trevor.secretlab.ca>
Date:	Wed, 27 Aug 2014 11:34:32 +0100
From:	Grant Likely <grant.likely@...aro.org>
To:	Mark Rutland <mark.rutland@....com>,
	Alexander Holler <holler@...oftware.de>
Cc:	Thierry Reding <thierry.reding@...il.com>,
	Jon Loeliger <jdl@....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)

On Tue, 26 Aug 2014 11:11:07 +0100, Mark Rutland <mark.rutland@....com> wrote:
> On Tue, Aug 26, 2014 at 10:42:04AM +0100, 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@...il.com> 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.
> 
> While having type information in the DTB would be fantastic, it's not
> something we can expect from the systems already in the wild, and I
> worry how it would interact with bootloaders that modify the DTB (I
> don't know if any modify properties with phandles).

Anything we do here is firmly in the realm of optimization and
improvement. Adding data to the tree is fine as long as we don't make
the kernel depend on it. Older platforms will continue to work without
the optimization.

> > The latter is impracticable to implement in a generic way (for use
> > with every possible binding).
> 
> I don't think we necessarily need dependency information for every
> binding and driver. We only need dependency information where a device
> has a dependency on another device and we don't currently have an
> explicit probe ordering guaranteed by Linux.
> 
> Where a device driver lacks dependency information and fails to probe,
> we can fall back to the current deferred probing.

Exactly.

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