On Mon, 13 Jan 2025 15:44:29 +0000
Mark Brown <broonie@xxxxxxxxxx> wrote:
> On Mon, Jan 13, 2025 at 04:26:20PM +0100, Kory Maincent wrote:
> > Mark Brown <broonie@xxxxxxxxxx> 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
