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]
Message-ID: <CAJZ5v0iJcTg=X_j-4nap9d_H4jq2rwOETT8Sukx6UL5UsDKjgA@mail.gmail.com>
Date:   Wed, 13 Jun 2018 10:27:39 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Srinath Mannam <srinath.mannam@...adcom.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: ACPI support in common clock framework

On Wed, Jun 13, 2018 at 10:13 AM, Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> +Cc: Rafael, ACPI ML
>
> On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam
> <srinath.mannam@...adcom.com> wrote:
>> Hi Michael, Stephen,
>>
>> We are adding ACPI support in our Linux based platform.
>> At present our clock hierarchy using common clock framework through DTS.
>> Now we required ACPI support in common clock framework to upgrade our platform.
>>
>> For example, clk_get API called in many drivers to get clock device is
>> tightly coupled with DT framework.
>>
>> Please let us know, if anybody in Open Source community have plans to
>> add ACPI support for common clock framework.

There are no plans for doing that AFAICS.

Moreover, it generally would not be consistent with ACPI power
management defined by the specification.

>> If not please suggest us alternative method to use common clock
>> framework in ACPI use case.

The problem with using the clock framework on systems with ACPI is
that, in general, the clock manipulation is expected to be carried out
by ACPI power management and therefore it is "owned" by AML.
Currently, there are no defined methods for synchronizing the AML's
use of clocks for power management with what the OS may do with them
directly.

In theory, that can be worked around to some extent by representing
clocks as power resources in ASL (even though the provider information
would be missing then) and manipulating those power resources directly
from the OS.  I'm not aware of anyone doing that successfully,
however.

For simple power management it should be sufficient to let drivers
rely on the ACPI PM domain which should happen automatically in the
majority of cases anyway.

Thanks,
Rafael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ