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: <20250114145328.437a3375@kmaincent-XPS-13-7390>
Date: Tue, 14 Jan 2025 14:53:28 +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 15:44:29 +0000
Mark Brown <broonie@...nel.org> wrote:

> On Mon, Jan 13, 2025 at 04:26:20PM +0100, Kory Maincent wrote:
> > Mark Brown <broonie@...nel.org> wrote:  
> > > On Mon, Jan 13, 2025 at 03:45:51PM +0100, Kory Maincent wrote:  
>  [...]  
> 
> > > 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;  
> 
> Yup, indeed.  That said I am wondering if it's safer to just configure
> the constraint in the hardware rather than the currently requested
> limit, considering what might happen in the case where there's multiple
> consumers that have only been partially updated.  If the hardware limits
> or shuts down rather than warning it'll blow up badly so it might be
> better to be conservative.  Unfortunately we don't distinguish in the
> ops.  Possibly it should be a policy thing even but then that's better
> at runtime...

Indeed, should we begin without it and see later if we add it?

We could simply add an event for now:
regulator_notifier_call_chain(rdev, REGULATOR_EVENT_OVER_CURRENT, NULL);

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