linux-kernel - Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

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: <c31cffa6-160a-de29-4ee7-fd74fc9cc743@arm.com>
Date:   Fri, 20 Jan 2017 14:18:40 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Kevin Hilman <khilman@...libre.com>
Cc:     Sudeep Holla <sudeep.holla@....com>, Tero Kristo <t-kristo@...com>,
        Dave Gerlach <d-gerlach@...com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Nishanth Menon <nm@...com>, Keerthy <j-keerthy@...com>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Lokesh Vutla <lokeshvutla@...com>
Subject: Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains



On 20/01/17 14:00, Ulf Hansson wrote:
> + Sudeep
> 
> On 19 January 2017 at 00:03, Rob Herring <robh@...nel.org> wrote:

>>
>> We could continue to use the power domain binding (maybe we already
>> are and that ship has sailed). I'm not totally against the idea even
>> if there is no power domain, but I'm not sold on it either. If we do
>> go this route, then I still say the id should be a cell in the
>> power-domain phandle.
>>
>> Another option is create something new either common or TI SCI
>> specific. It could be just a table of ids and phandles in the SCI
>> node. I'm much more comfortable with an isolated property in one node
>> than something scattered throughout the DT.
> 
> To me, this seems like the best possible solution.
> 
> However, perhaps we should also consider the SCPI Generic power domain
> (drivers/firmware/scpi_pm_domain.c), because I believe it's closely
> related.
> To change the power state of a device, this PM domain calls
> scpi_device_set|get_power_state() (drivers/firmware/arm_scpi.c), which
> also needs a device id as a parameter. Very similar to our case with
> the TI SCI domain.
> 
> Currently these SCPI device ids lacks corresponding DT bindings, so
> the scpi_pm_domain tries to work around it by assigning ids
> dynamically at genpd creation time.
> 

IIUC do you mean the binding for the power domain provider to have a
list of domain ids ? If so yes, we don't have one.

But the idea was to have the range to be continuous and create genpd for
the complete range. Though the SCPI specification lacked a command to
get the max. no. of domains supported. That's the reason we had to
introduce the num-domains(*) which may be optional if we have firmware
interface to obtain that information.

-- 
Regards,
Sudeep

(*) P.S: but it has been considered for SCMI(which is an improvement and
more flexible/extensible replacement/upgrade to SCPI) which will be
released soon.