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: 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:25:36 +0000
From:   Mark Brown <>
To:     Furquan Shaikh <>
Cc:     "Rafael J. Wysocki" <>,
        "Rafael J . Wysocki" <>,
        Liam Girdwood <>,
        Tony Lindgren <>,
        Dmitry Torokhov <>,
        Len Brown <>,
        Greg Kroah-Hartman <>,
        Lorenzo Pieralisi <>,
        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 <>,
        Mark Rutland <>,
        Aaron Durbin <>,
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).

You're missing the point here.  What we're saying is that if you want to
do this using ACPI you should extend ACPI to support this directly so
where regulators need to be controlled by the OS there's a clear
understanding of how this interacts with the rest of the ACPI power

> 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.
> How can we achieve this?

Consumers already don't know they're using DT, there's no reason they
should have any impact from ACPI either except possibly a bit of name
translation for ACPI's idiomatic naming conventions.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists