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