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:   Fri, 20 Jan 2017 17:52:03 +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

[...]

>>> 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.

Or am I missing something here?

Regarding something "common/generic", I was merely thinking of some
common bindings describing the list of phandle to device ids mapping.
However, let's not make this more complicated than it is already. So
please just ignore my suggestion so we can make this work for your
case first.

However, maybe I didn't fully understood Rob's suggestion. Perhaps Rob
can clarify once more.

Anyway, this is how interpreted Rob's suggestion:

TISCI_PM_DOMAIN_DEVLIST: tisci-pm-domain-devlist {
     devs = <&serial0>, <&mmc0>;
     devids = <5 10>;
}

With this, you should be to extract the devid which corresponds to the
device that has been attached to the TI SCI PM domain. Don't you
think?

Kind regards
Uffe