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

[Krzysztof Kozlowski]

On 22/08/2023 17:18, Shenwei Wang wrote:
> 
> 
>> -----Original Message-----
>> From: Rob Herring <robh+dt@xxxxxxxxxx>
>> Sent: Monday, August 21, 2023 1:50 PM
>> To: Shenwei Wang <shenwei.wang@xxxxxxx>
>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>; Krzysztof Kozlowski
>> <krzysztof.kozlowski+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>;
>> Ulf Hansson <ulf.hansson@xxxxxxxxxx>; Liam Girdwood
>> <lgirdwood@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>;
>>> 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