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 17:54:58 +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 05:08:38PM +0200, Tomeu Vizoso wrote:
> On 26 May 2015 at 11:36, Mark Brown <broonie@...nel.org> wrote:

> > Yes, x86 based embedded systems use ACPI (and we really ought to be
> > trying to help systems using board files too for that matter).

> Yes, I see how registering devices on-demand could be implemented for
> all those, but what I don't see is how they would benefit from it.

You'd need to be clearer about what problem you're trying to solve
there, which is something you left us guessing at!

> I can see an hypothetical maintenance benefit in sharing as much code
> as possible between these different scenarios, but in this case,
> because this feature is so closely tied to machine description I think
> complexity would be actually bigger.

We've now got abstractions for common firmware operations (look at the
fwnode stuff) and this isn't exactly deep introspection here.

If you're trying to solve the probe order problem you can probably get a
long way by just doing something that boils down to "try to instantiate
everything referenced from this node" which could probably even be
kicked from the driver core prior to probe and cover most cases.  Or put
this into the node lookup interface so we try to instantiate everything
we reference.

> On machines that have ACPI, most of those devices aren't exposed to
> the kernel and few or no deferred probes happen (though I have only
> tested on qemu and Minnowboard MAX, both with no deferred probes).

On the machines that you happen to have looked at; I would rather expect
that x86 based phones will be in a similar situation once they move to
ACPI which they should be doing this year if they didn't already, and
the embedded systems will doubtless run into this once they have any
meaningful hardware on them (the base Minnoboard isn't really
interesting here, it's once you build a system on top of that).

> On machines with board files, devices are registered in a
> predetermined order, presumably without any deferred probes.

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.

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

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