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]

Date:   Tue, 22 Aug 2023 15:18:06 +0000
From:   Shenwei Wang <shenwei.wang@....com>
To:     Rob Herring <robh+dt@...nel.org>
CC:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.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: Rob Herring <robh+dt@...nel.org>
> Sent: Monday, August 21, 2023 1:50 PM
> To: Shenwei Wang <shenwei.wang@....com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@...aro.org>; Conor Dooley <conor+dt@...nel.org>;
> Ulf Hansson <ulf.hansson@...aro.org>; Liam Girdwood
> <lgirdwood@...il.com>; Mark Brown <broonie@...nel.org>;
> > Thank you for providing the link. After reviewing the entire thread, I
> > still don't understand how to proceed. What is the conclusion
> > regarding this commonly used use case but overlooked feature in the
> upstream kernel?
> 
> Overlooked implies we missed and ignored it, but the same concept has been
> submitted twice and rejected twice. What use case cannot be supported?
> 

No offend. :) Sorry for my poor word. To provide more context, a common use case 
example is using a GPIO pin as a power switch. The current implementation operates 
as a fixed regulator, which makes it difficult to control the on/off timing without modifying
its driver. It also lacks power management support. 

> The detail that power-domains get handled automatically is an implementation
> detail in the kernel (currently). That could easily change and you'd be in the same
> position as with regulator supplies.

The proposed regulator-pd driver follows the standard PD driver framework, so it for sure
relies on certain kernel implementation details. If those underlying implementation details 
change in the future, this driver as well as other PD drivers built on the same framework 
would need to be updated accordingly. 

> We could just as easily decide to make the driver core turn on all supplies in a
> node. That would give you the same "feature". Why would you design your DT
> around implementation decisions of the OS?
> 

This DT properties are proposed solely for this specific driver, not to hack the OS. This 
is no different than other PD drivers like gpc/scu-pd/imx93-pd.

Thanks,
Shenwei

> Rob