[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150526093601.GH21577@sirena.org.uk>
Date: Tue, 26 May 2015 10:36:01 +0100
From: Mark Brown <broonie@...nel.org>
To: Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Stéphane Marchesin
<stephane.marchesin@...il.com>,
Thierry Reding <thierry.reding@...il.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Alexander Holler <holler@...oftware.de>,
Grant Likely <grant.likely@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Liam Girdwood <lgirdwood@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 10/21] regulator: core: Probe regulators on demand
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).
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists