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: <CAL_JsqJ3dr7gxq+D5DYG8oQ=igzjARz=beQoYL7rrydV4SwDTw@mail.gmail.com>
Date:   Mon, 21 Aug 2023 13:49:34 -0500
From:   Rob Herring <robh+dt@...nel.org>
To:     Shenwei Wang <shenwei.wang@....com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        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: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file

On Mon, Aug 21, 2023 at 8:22 AM Shenwei Wang <shenwei.wang@....com> wrote:
>
>
>
> > -----Original Message-----
> > From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> > Sent: Saturday, August 19, 2023 3:04 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
> >
> > Caution: This is an external email. Please take care when clicking links or
> > opening attachments. When in doubt, report the message using the 'Report this
> > email' button
> >
> >
> > >>
> > >> This needs to answer why we need this.
> > >>
> > >> It looks like just an abstraction layer to make regulators look like
> > >> a power domain.
> > >>
> > >
> > > Yes, it is a wrapper that allows using regulators as a power domain.
> > > This removes the need to add regulator operating code in each consumer
> > > device driver. As a power domain, the regulator will be managed
> > > automatically by the device driver framework and PM subsystem.
> > >
> > > This is very useful when a device's power is controlled by a GPIO pin,
> > > which currently requires using the fixed-regulator to achieve the same
> > > purpose. However, the fixed-regulator approach may have to add code in the
> > driver in order to use it.
> >
> > Why do you start discussion from zero ignoring all previous history of this
> > patchset?
> >
>
> Thank you for providing the link. After reviewing the entire thread, I still don't understand how
> to proceed. What is the conclusion regarding this commonly used use case but overlooked feature
> in the upstream kernel?

Overlooked implies we missed and ignored it, but the same concept has
been submitted twice and rejected twice. What use case cannot be
supported?

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.
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?

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ