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: <E1XLv1z-0002Jv-VN@jdl.com>
Date:	Mon, 25 Aug 2014 09:13:59 -0500
From:	Jon Loeliger <jdl@....com>
To:	Thierry Reding <thierry.reding@...il.com>
cc:	Mark Rutland <mark.rutland@....com>,
	Alexander Holler <holler@...oftware.de>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"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)

> 
> 
> > I believe some of the issues that need to be resolved are:
> >
> >     1) What constitutes a dependency?
> >     2) How is that dependency expressed?
> >     3) How do we add missing dependencies?
> >     4) Backward compatability problems.
> >
> > There are other questions, of course.  Is it a topsort
> > per bus?  Are there required "early devices"?  Should
> > the inter-node dependencies be expressed at each node,
> > or in a separate hierarchy within the DTS?  Others.
> 
> I think Grant already objected to the idea of explicitly adding
> dependency information into the device tree sources.

Clearly, the reason to object to the introdcution of such
an artificial dependency implies that it would be trying
to express something that doesn't actually describe an
existing hardware requirement.  That is, it wouldn't be
"describing hardware".  That's fine.

But the inverse should also be true.  That is, we should
ensure that where there *is* a hardware dependency that
is currently not expressed, we should introduce that
relationship.


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

So, express the "additional SW dependencies" in the SW?

> Clocks are usually not a problem with deferred probing since they often
> are registered early anyway.

Ah, but how are they known to be needed early?  A toposort should sort
them into that position.  That's not currently done.  And I doubt the
set of nodes and expressed dependencies would cause them to be done
early enough by today's standards.

> Regulators on the other hand seem to be a fairly common trigger,
> though, so they seem like a good candidate to focus on.

Yeah.  And I've seen some debatable IRQ-PHY-PCIe interaction too.

> Thierry

jdl
--
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/