linux-kernel - Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file

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: <8f9f24c7-c93f-4cb8-bbd2-f0a8502d5f1b@linaro.org>
Date:   Mon, 28 Aug 2023 12:45:20 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Shenwei Wang <shenwei.wang@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        "imx@...ts.linux.dev" <imx@...ts.linux.dev>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file

On 28/08/2023 11:59, Ulf Hansson wrote:
> On Sat, 26 Aug 2023 at 19:31, Krzysztof Kozlowski
> <krzysztof.kozlowski@...aro.org> wrote:
>>
>> On 25/08/2023 17:44, Shenwei Wang wrote:
>>>>
>>>> The genpd provider then needs to be a consumer of the resources it needs. In
>>>> this case a couple of regulators it seems like.
>>>>
>>>
>>> If I understood your reply correctly,  it seems that the current implementation of
>>> regulator-pd is what you have described. Please correct me if I'm mistaken.
>>>
>>> The following are the diff of scu-pd and this regulator-pd.
>>>
>>>     power-controller {                                                    power-controller {
>>>         compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";      |               compatible = "regulator-power-domain";
>>>         #power-domain-cells = <1>;                                    #power-domain-cells = <1>;
>>>                                                             >
>>>                                                             >         regulator-number = <2>;
>>>                                                             >         regulator-0-supply = <&reg1>;
>>>                                                             >         regulator-1-supply = <&reg2>;
>>>     };                                                                    };
>>>
>>> Are you suggesting to move the regulator-pd to the imx directory and add a company prefix
>>> to the compatible string?
>>
>> There is no such part of iMX processor as such regulator-power-domain,
>> so I don't recommend that approach. DTS nodes represent hardware, not
>> your SW layers.
> 
> I would agree if this was pure SW layers, but I don't think it is. At
> least, if I have understood the earlier discussions correctly [1],
> there are certainly one or more power-domains here. The power-domains
> just happen to be powered through something that can be modelled as a
> regular regulator(s). No?

No. It was for controlling power of multiple devices, supplied by
multiple different or similar regulators, where Linux drivers for these
devices (so not even all drivers...) do not have regulator control. The
bindings for these devices allow power-domains, but not regulator.

There are no multiple power domains in the problem. Even term "power
domain" is questionable here, because we tend to look power domain as
part of SoC. Here it is some selected part of the circuitry, like few
totally independent devices which share purpose and power rails.

But more important is my first paragraph - this is purely to avoid
adding regulators to these devices.

Best regards,
Krzysztof