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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7hlgy0frlb.fsf@baylibre.com>
Date:   Fri, 07 Oct 2016 02:14:56 -0700
From:   Kevin Hilman <khilman@...libre.com>
To:     Jon Hunter <jonathanh@...dia.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>
Subject: Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

Jon Hunter <jonathanh@...dia.com> writes:

> Some devices may require more than one PM domain to operate and this is
> not currently by the PM domain framework. Furthermore, the current Linux
> 'device' structure only allows devices to be associated with a single PM
> domain and so cannot easily be associated with more than one. To allow
> devices to be associated with more than one PM domain, if multiple
> domains are defined for a given device (eg. via device-tree), then:
> 1. Create a new PM domain for this device. The name of the new PM domain
>    created matches the device name for which it was created for.
> 2. Register the new PM domain as a sub-domain for all PM domains
>    required by the device.
> 3. Attach the device to the new PM domain.

Did you look at what might be involved to extend struct device to hace a
list of pm_domains?  Like Ulf, I'm a bit unsettled by this
implementation that has to work around the basic limitation in the
driver model.

Having devices in multitple domains is needed for SoCs I'm familiar with
also, so is a needed feature.

I think removing the struct device limitation and corresponding
assumptions in the driver and PM core is a prerequisite for this
feature.

Doing that will lead to several questions about how to handle runtime PM
operations (e.g. which of the multiple PM domains should the one to call
the drivers runtime PM hooks when a device changes runtime PM state?)

Anyways, even with the potential complexities, I think attempting this
is the right way forward.

Kevin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ