> -----Original Message----- > From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > Sent: Tuesday, August 22, 2023 10:58 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: Re: [EXT] Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml > file > > > > > That is arguable too. The driver may assume its power is on when > > probed, which aligns with how the PD behaves. > > So everything in driver... no discussion about bindings. > That's true only when you have a PD driver for it. > > > >>> 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. > > You can create any drivers you wish or change existing ones. I don't see a > problem here. > That's what this patch set does. > > > >>> > > > > As a new driver, it has to involve some new bindings especially the > > compatible string. > > I am not talking about this. I do not speak about creating new bindings, but > changing them. I'm a bit confused by your statement. The patch only creates some necessary new bindings for the new driver. It doesn't change any existing bindings. > > > >>> > > 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. > > Since bindings are not for software layers, I don't think we should be talking > about them just to avoid introducing driver changes. > While it is a software layer, it is a driver that requires bindings. I don't think you would recommend hardcoding those properties inside the driver itself. Thanks, Shenwei > Best regards, > Krzysztof
