linux-kernel - Re: RFC power domain vs generic supply regulator

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] [day] [month] [year] [list]

Message-ID: <20210805175843.GS26252@sirena.org.uk>
Date:   Thu, 5 Aug 2021 18:58:43 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Michael Nazzareno Trimarchi <michael@...rulasolutions.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: RFC power domain vs generic supply regulator

On Thu, Aug 05, 2021 at 07:39:42PM +0200, Michael Nazzareno Trimarchi wrote:

> So in short you said that if I have a device that has no definition of
> supply in his
> documentation, this device needs to support the supply in his binding
> and make to sense
> to create something like:

> generic-supply = <&regulator_device>;

No, the bindings should use the specific names that the supplies have,
generally whatever the names they are given in the datasheet for the
device.  If the device has no actual supplies then it almost certainly
shouldn't be working with the regulator API.

> and let dd to pick them up

No, the driver for the device should handle things.  The code is pretty
trivial, though if someone wants to write helpers then sure.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)