[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170125183420.GC25470@leverpostej>
Date: Wed, 25 Jan 2017 18:34:20 +0000
From: Mark Rutland <mark.rutland@....com>
To: Mark Brown <broonie@...nel.org>
Cc: Furquan Shaikh <furquan@...omium.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Liam Girdwood <lgirdwood@...il.com>,
Tony Lindgren <tony@...mide.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Len Brown <lenb@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Hanjun Guo <hanjun.guo@...aro.org>,
Will Deacon <will.deacon@....com>,
Rob Herring <robh@...nel.org>,
Sathyanarayana Nujella <sathyanarayana.nujella@...el.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Adam Thomson <Adam.Thomson.Opensource@...semi.com>,
Linus Walleij <linus.walleij@...aro.org>,
Alexandre Courbot <gnurou@...il.com>,
linux-gpio@...r.kernel.org,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
Aaron Durbin <adurbin@...omium.org>, dlaurie@...omium.org
Subject: Re: [PATCH 0/7] Implement generic regulator constraints parsing for
ACPI and OF
On Wed, Jan 25, 2017 at 06:29:55PM +0000, Mark Brown wrote:
> On Wed, Jan 25, 2017 at 06:23:20PM +0000, Mark Rutland wrote:
> > On Wed, Jan 25, 2017 at 08:56:42AM -0800, Furquan Shaikh wrote:
>
> > > That is the reason why the recent change to add ACPI support to fixed
> > > regulators was done
> > > (https://github.com/torvalds/linux/blob/master/drivers/regulator/fixed.c#L100).
>
> > To be honest, I'm surprised this got merged.
>
> My understanding was that it was instantiated from another device as an
> implementation detail of that device, letting it say "this GPIO should
> be handled as a regulator".
>
> > Mark, this was added in this cycle; can we please rip that out for now?
>
> If it's instantiated directly we probably should.
I think that given the larger problem that needs to be addressed here,
and how the us of DSD properties muddies the water, it would be
preferable to remove it until we have some consensus.
> > We can certainly come up with something that allows drivers to support
> > both, but trying to do this without updating drivers opens a huge set of
> > problems.
>
> I think there's a reasonable chance that any ACPI specs could be written
> in such a way as to allow transparent support in Linux, the main thing
> I'd worry about is naming issues.
I think it's certainly possible to handle this so that drivers don't
largely have to care. I also think there is some massaging the needs to
be done (e.g. tables of names or some indirection for ACPI/DT
differences), and a unified API that tries to completely hide that is
not truly possible.
Thanks,
Mark.
Powered by blists - more mailing lists