linux-kernel - Re: [PATCH 1/2] regulator: Add support for power budget

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: <b184e29e-06b0-49cf-8469-1fa0778f06e7@sirena.org.uk>
Date: Mon, 13 Jan 2025 14:51:53 +0000
From: Mark Brown <broonie@...nel.org>
To: Kory Maincent <kory.maincent@...tlin.com>
Cc: Liam Girdwood <lgirdwood@...il.com>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	Oleksij Rempel <o.rempel@...gutronix.de>, kernel@...gutronix.de
Subject: Re: [PATCH 1/2] regulator: Add support for power budget

On Mon, Jan 13, 2025 at 03:45:51PM +0100, Kory Maincent wrote:
> Mark Brown <broonie@...nel.org> wrote:

> > joining it up with the power limiting.  It's fortunately not used
> > dynamically by anything at the minute so we could just remove that API
> > and replace it by a power one, given that nobody uses it and there do
> > appear to be users for the power based API.  We do have some things that
> > set current limits in constraints IIRC.

> There is few users for the regulator_set_current_limit function.
> https://elixir.bootlin.com/linux/v6.12.6/A/ident/regulator_set_current_limit

> Not sure we could replace it to power limit that easily.

Huh, I wonder what tree I grepped in.  The DRM usage is yet more broken
usage of the regulator API, I'm not sure why it attracts this so much,
but the others are legit.  Still, we should be able to map between the
two.

> > We probably also need something explicit about how we handle baseline
> > load from things like passive components, the assumption probably needs
> > to be that it's negligable.

> We could add a devicetree property on the consumer node, but lets keep it for
> later.

One problem is that there might not be a consumer node - things like
random passives don't tend to get represented.

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