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: <PAXPR04MB9185F6AA20B0440B8FAB847789E3A@PAXPR04MB9185.eurprd04.prod.outlook.com>
Date:   Fri, 25 Aug 2023 15:44:55 +0000
From:   Shenwei Wang <shenwei.wang@....com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
CC:     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



> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@...aro.org>
> Sent: Friday, August 25, 2023 7:25 AM
> To: Shenwei Wang <shenwei.wang@....com>
> Cc: 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; devicetree@...r.kernel.org; linux-kernel@...r.kernel.org;
> dl-linux-imx <linux-imx@....com>
> Subject: [EXT] Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
> 
> 
> On Thu, 24 Aug 2023 at 18:35, Shenwei Wang <shenwei.wang@....com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Ulf Hansson <ulf.hansson@...aro.org>
> > > Sent: Thursday, August 24, 2023 4:27 AM
> > > To: Shenwei Wang <shenwei.wang@....com>
> > > Cc: 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;
> > > devicetree@...r.kernel.org; linux-kernel@...r.kernel.org;
> > > dl-linux-imx <linux-imx@....com>
> > > Subject: [EXT] Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd
> > > yaml file
> > >
> > > Caution: This is an external email. Please take care when clicking
> > > links or opening attachments. When in doubt, report the message
> > > using the 'Report this email' button
> > >
> > >
> > > On Fri, 18 Aug 2023 at 17:35, Shenwei Wang <shenwei.wang@....com>
> wrote:
> > > >
> > > > Documenting the regulator power domain properties and usage examples.
> > >
> > > As Rob and Krzysztof already pointed out, I agree that this binding
> > > looks a bit questionable.
> > >
> > > Rather than adding a new DT binding, why can't we just use the
> > > existing way of describing a platform specific power-domain provider?
> >
> > Can you please provide more details on how you thought we should
> > implement this feature using the existing way? Very appreciate if you could
> provide a simple example.
> >
> > > This still looks platform specific to me.
> >
> > What does platform specific exactly mean here?  I want to make sure I
> > understand what you were referring to.
> 
> There are plenty of examples of how a platform specific genpd provider looks in
> DT. You may have a look a imx platforms for example.
> 
> git grep "#power-domain-cells" arch/arm/boot/dts/nxp/imx
> 
> 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?

Thanks,
Shenwei

> [...]
> 
> Kind regards
> Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ