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

Message-ID: <20210805172300.GR26252@sirena.org.uk>
Date:   Thu, 5 Aug 2021 18:23:00 +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 Tue, Jun 08, 2021 at 08:01:20AM +0200, Michael Nazzareno Trimarchi wrote:

> I'm trying to understand how to deal with devices that do not provide
> a supply handle connection using the device tree, or if there is a
> generic way
> to connect to a regulator. The pinctrl has a generic binding inside
> dd.c that allow to mux pinout during probing or it allows to define a
> power domain,
> According to the code I read the power domain can be only connected to
> the SoC power domain but in general a generic power domain can be
> connected
> to any source aka a regulator. For example and spi-nor can be powered
> but a gpio regulator or any kind of supply connection and bunch of
> devices
> can just need a supply if they are probed or binded runtime. Can
> someone give me feedback on this topic?

I'm having a really hard time parsing the issue you're trying to solve
here.  Power domains and regulators are different things, power domains
represent blocks with a SoC which have some kind of power control which
may involve a combination of things, the drivers for the devices within
those domains generally just do runtime PM and then let the driver core
figure out what's going on with them.  Regulators are for things with
physical supplies that can be seen in the schematic for the board, in
general anything that uses a regulator should explicitly say so in its
binding - supporting some sort of generic mapping isn't great since it
means that we don't have any control over which regulator is which and
that makes it hard to add control of the regulators later.  Power
domanis may possibly have regulators among the resources they use but
that would just be a normal device binding for the power domain.  All of
this is orthogonal to when drivers for devices get loaded, that can
happen at any point while the system is running and doesn't really
affect how the relationships are described.

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