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: <20250113162620.3c244302@kmaincent-XPS-13-7390>
Date: Mon, 13 Jan 2025 16:26:20 +0100
From: Kory Maincent <kory.maincent@...tlin.com>
To: Mark Brown <broonie@...nel.org>
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, 13 Jan 2025 14:51:53 +0000
Mark Brown <broonie@...nel.org> wrote:

> 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 could have something like that in regulator_request_power_budget()?

if (rdev->desc->ops->get_voltage && rdev->desc->ops->set_current_limit) {
	ret = regulator_get_voltage(rdev);
	if (ret < 0)
		return ret;

	tmp_64 = pw_req;
	tmp_64 *= 1000000000ull;
	/* uA = mW * 1000000000 / uV */
	uA = DIV_ROUND_CLOSEST_ULL(tmp_64, uV);
	ret = regulator_set_current_limit(rdev, uA);
	if (ret)
		return ret;
}

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

Mmh true, so indeed if they are not represented lets assume they are
negligible. ;)

-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com