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]

Date:   Tue, 24 Jan 2017 11:03:48 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Dave Gerlach <d-gerlach@...com>
Cc:     Rob Herring <robh@...nel.org>, Kevin Hilman <khilman@...libre.com>,
        Tero Kristo <t-kristo@...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>,
        Sudeep Holla <sudeep.holla@....com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Lokesh Vutla <lokeshvutla@...com>
Subject: Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

On 23 January 2017 at 21:11, Dave Gerlach <d-gerlach@...com> wrote:
> On 01/20/2017 10:52 AM, Ulf Hansson wrote:
>>
>> [...]
>>
>>>>> 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.
>>>>
>>>> That makes me wonder, whether we should think of something
>>>> common/generic?
>>>
>>>
>>> When you say something common/generic, do you mean a better binding for
>>> genpd,
>>> or something bigger than that like a new driver? Because I do think a
>>> phandle
>>> cell left open for the genpd provider to interpret solves both the scpi
>>> and
>>> ti-sci problem we are facing here in the best way. Using generic PM
>>> domains lets
>>> us do exactly what we want apart from interpreting the phandle cell with
>>> our
>>> driver, and I feel like anything else we try at this point is just going
>>> to be
>>> to work around that. Is bringing back genpd xlate something we can
>>> discuss?
>>
>>
>> Bringing back xlate, how would that help? Wouldn't that just mean that
>> you will get one genpd per device? That's not an option, I think we
>> are all in agreement to that.
>
>
> Sure, perhaps the custom xlate wouldn't be the right way to do it, as we
> wouldn't be able to associate a device directly to a phandle, at least with
> how it was implemented before, but I think we can skip that entirely. Does
> opening up the interpretation of the cells of the 'power-domains' phandle
> not solve all of these issues? Is that out of the question?
>
> genpd_xlate_simple currently just makes sure the args_count of the
> 'power-domains' phandle was zero and bails if it was not. Why couldn't we
> remove this check and let the driver interpret it while still using
> of_genpd_add_provider_simple to register the provider? It's still a 'simple'
> provider from the perspective of the genpd framework and the actual pm
> domain mapping will not change, but now the driver can parse the cells and
> do whatever it needs to, such as reading a device id.
>
> I think that's a bit more flexible and will avoid breaking anything that is
> there today.

Would you mind providing an example? Perhaps also some code snippets
dealing with the parsing?

Kind regards
Uffe