linux-kernel - Re: [PATCH 10/21] regulator: core: Probe regulators on demand

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]

Date:	Tue, 26 May 2015 20:55:27 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc:	Mark Rutland <mark.rutland@....com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Stéphane Marchesin 
	<stephane.marchesin@...il.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Alexander Holler <holler@...oftware.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 10/21] regulator: core: Probe regulators on demand

On Tue, May 26, 2015 at 07:53:33PM +0200, Tomeu Vizoso wrote:
> On 26 May 2015 at 18:54, Mark Brown <broonie@...nel.org> wrote:

> >> My understanding is that the problem I'm addressing is specific of
> >> machines in which the kernel is in charge of pretty much everything
> >> and that the information about what devices are present is given in an
> >> arbitrary order.

> > I don't think you've fully understood the problem space here.
> 
> Fair enough, what's your understanding of it?

Basically what I said in the e-mail you quoted fully in your reply,
especially this section:

> > No, not in the least.  Quite aside from anything else as soon as you
> > allow things to be built as modules userspace is free to load things in
> > whatever order amuses it.  Think about what's going on here - it's not
> > just registration of devices, it's also about the order in which
> > subsystems and drivers register themselves.

Probe ordering is fairly weakly related to the interface used to
register devices, you're going to get dependencies more often the more
detail is exposed to the kernel but it's not specific to that.  It's
definitely not something that we have a solution to for board files,
they rely on deferred probing just as much as device tree does.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)