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]

Date:   Tue, 22 Aug 2023 17:57:56 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
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" <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

On 22/08/2023 17:50, Shenwei Wang wrote:
> 
> 
>> -----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.

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