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:08:38 +0200
From:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
To:	Mark Brown <broonie@...nel.org>
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 26 May 2015 at 11:36, Mark Brown <broonie@...nel.org> wrote:
> On Tue, May 26, 2015 at 08:17:23AM +0200, Tomeu Vizoso wrote:
>> On 25 May 2015 at 19:32, Mark Brown <broonie@...nel.org> wrote:
>
>> > The obvious questions here based on the name are why we're doing
>> > something specific to platform devices and why this isn't something
>> > we're abstracting in the driver core (or at least generic firmware code)
>> > - we're going to have the same thing with ACPI.
>
>> I don't know how useful this is going to be in systems with ACPI. My
>> experience is limited to 32bit ARM, where the kernel has to manage
>> every regulator, clock, gpio, etc so the dependency tree is so big. Is
>> deferred probing a problem with ACPI as well?
>
> 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.

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.

The problem I'm trying to address only manifests on systems with
dozens of devices that are currently registered in an arbitrary order
(as they are in the DT).

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 machines with board files, devices are registered in a
predetermined order, presumably without any deferred probes.

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.

Deferred probe gives us reliably a working system at the end for these
machines, but in the meantime some devices will have been deferred
several times and when they get to probe the user will have noticed
the delay.

Regards,

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