On 22/08/2023 17:50, Shenwei Wang wrote: > > >> -----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. So everything in driver... no discussion about bindings. > >>> 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. > >>> >>>> 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. I am not talking about this. I do not speak about creating new bindings, but changing them. > >>> >>>> 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. Since bindings are not for software layers, I don't think we should be talking about them just to avoid introducing driver changes. Best regards, Krzysztof
