> -----Original Message----- > From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > Sent: Tuesday, August 22, 2023 10:26 AM > To: Shenwei Wang <shenwei.wang@xxxxxxx>; Rob Herring > <robh+dt@xxxxxxxxxx> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>; Conor Dooley > <conor+dt@xxxxxxxxxx>; Ulf Hansson <ulf.hansson@xxxxxxxxxx>; Liam Girdwood > <lgirdwood@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>; > imx@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > dl-linux-imx <linux-imx@xxxxxxx> > Subject: [EXT] Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file > > > > 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? > That is arguable too. The driver may assume its power is on when probed, which aligns with how the PD behaves. > > It also lacks power management support. > > Which is not related to bindings but implementation in given driver. > For those simple drivers, the default power management logic can handle power correctly without requiring any specialized implementation in the driver code. > > > >> 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... > As a new driver, it has to involve some new bindings especially the compatible string. > > > >> 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. > Thank you for the clarification. The issue is that this driver is purely a software layer that wraps the regulators as a power domain. The bindings make the implementation clean and easy to understand. I don't think we should add extra complex logic inside the driver solely to avoid introducing new bindings. Thanks, Shenwei > Best regards, > Krzysztof
