linux-kernel - RE: [EXT] Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <PAXPR04MB9185F7B520E8BE94B97C4908891FA@PAXPR04MB9185.eurprd04.prod.outlook.com>
Date:   Tue, 22 Aug 2023 15:50:18 +0000
From:   Shenwei Wang <shenwei.wang@....com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Rob Herring <robh+dt@...nel.org>
CC:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        "imx@...ts.linux.dev" <imx@...ts.linux.dev>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: RE: [EXT] Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml
 file



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> Sent: Tuesday, August 22, 2023 10:26 AM
> To: Shenwei Wang <shenwei.wang@....com>; Rob Herring
> <robh+dt@...nel.org>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>; Conor Dooley
> <conor+dt@...nel.org>; Ulf Hansson <ulf.hansson@...aro.org>; Liam Girdwood
> <lgirdwood@...il.com>; Mark Brown <broonie@...nel.org>;
> imx@...ts.linux.dev; devicetree@...r.kernel.org; linux-kernel@...r.kernel.org;
> dl-linux-imx <linux-imx@....com>
> 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