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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux