linux-kernel - Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

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:   Wed, 25 Jan 2017 18:23:20 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Furquan Shaikh <furquan@...omium.org>,
        Mark Brown <broonie@...nel.org>
Cc:     "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 08:56:42AM -0800, Furquan Shaikh wrote:
> I understand that ACPI provides its own bindings to allow firmware to
> control power management and thus regulators have been a part of the
> firmware control. However, there are use cases where the kernel driver
> wishes to control the regulator to manage power to the device
> irrespective of the way regulator is passed in (ACPI/OF).

It sounds like there is a deficiency in the ACPI spec, then.  That being
the case, this should be addressed within the ACPI spec (or at least in
conjunction with it), rather than attaching something unrelated onto the
side.

There are a number of problems with this approach, and other OSs are
facing the same set of problems. The ACPI spec and the ASWG are supposed
to provide a common ground where such issues get dealt with.

Using DSD to bypass the ASWG is creating a large set of problems for a
trivial expedience.

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

Mark, this was added in this cycle; can we please rip that out for now?

> It needs regulators for USB driver. Similarly, other drivers like ELAN
> touchscreen that plan to control power to the device in a generic way
> irrespective of OF/ACPI need to control regulators in kernel itself.
> The above change for adding ACPI support to fixed regulators is
> currently parsing only limited parameters and also does not work the
> same way for ACPI and OF, though it ends to introduce the regulators
> in a way similar to OF.

Having a consistent API is desirable. That does not imply that we should
invent a non-standard FW representation in ACPI, nor does it imply that
an API we have today is necessarily appropriate.

There are a number of different ways this could be addressed.

> We need to support existing drivers and use cases for power management
> in both OF and ACPI environments (keeping in mind that suspend to idle
> bypasses parts of firmware) without needing to change all the drivers.

I think that the goal here is broken, given existing model differences
between ACPI and DT.

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.

Thanks,
Mark.