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
