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 17:25:30 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Shenwei Wang <shenwei.wang@....com>,
        Rob Herring <robh+dt@...nel.org>
Cc:     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

On 22/08/2023 17:18, Shenwei Wang wrote:
> 
> 
>> -----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. 

So it is a problem of a driver?

> It also lacks power management support. 

Which is not related to bindings but implementation in given driver.

> 
>> 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 talk about bindings which you would not be allowed to change. Thus
your case would stop working...

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

I am not sure if you got Rob's point, I have feelings that not. Argument
that some OS implements something some way, is not an argument for a new
binding, barely hardware related.

Best regards,
Krzysztof