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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 25 Jan 2017 19:21:35 +0000
From:   Lorenzo Pieralisi <>
To:     Mark Brown <>
Cc:     Mark Rutland <>,
        Furquan Shaikh <>,
        "Rafael J. Wysocki" <>,
        "Rafael J . Wysocki" <>,
        Liam Girdwood <>,
        Tony Lindgren <>,
        Dmitry Torokhov <>,
        Len Brown <>,
        Greg Kroah-Hartman <>,
        Hanjun Guo <>,
        Will Deacon <>,
        Rob Herring <>,
        Sathyanarayana Nujella <>,
        Heikki Krogerus <>,
        Adam Thomson <>,
        Linus Walleij <>,
        Alexandre Courbot <>,,
        ACPI Devel Maling List <>,
        Linux Kernel Mailing List <>,
        Linux OMAP Mailing List <>,
        Aaron Durbin <>,
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
> > > (
> > 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.
> > 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 that the difference between ACPI and DT firmware models,
in particular in relation to power states handling (and what piece
of SW is in charge of power management) is significant and goes beyond
naming conventions, therefore the code (and reasoning behind it - ie
to have an identical driver interface to a completely different FW
model) in this series is just not acceptable, that's a plain shortcut.

We will see how this should be implemented in ACPI, not with this
code (and FW bindings).


Powered by blists - more mailing lists