Re: [PATCH net-next 3/4] net: pse-pd: realtek-pse-mcu: configure global power budget

[Jonas Jelonek <jonas@jonasjelonek.de>]

Hi Kory,

On 04.11.26 12:32, Kory Maincent wrote:
>
>
> On 11/3/26 23:03, Jonas Jelonek wrote:
>> Use the optional VMAIN regulator power budget to configure the MCU's
>> aggregate PoE power limit during probe. Quantize the available budget to
>> the protocol's 100 mW units and reserve exactly that amount through the
>> regulator core.
>>
>> The regulator budget represents the usable PoE allowance. Program zero
>> reserved power so the previous firmware guard band does not further reduce
>> that allowance.
>>
>> Require a finite budget of at least one protocol unit when vmain-supply is
>> provided. Program the budget before selecting dynamic power management and
>> ungating the ports, so enforcement starts with the regulator-derived limit.
>>
>> Enable VMAIN before hardware initialization and register one managed cleanup
>> action to free any reserved budget and release the enable reference on probe
>> failure and driver removal. Record each successful reservation immediately
>> so subsequent initialization failures are covered by this action.
>>
>> Read the current budget index before programming the MCU. Retain the
>> programmed MCU limit on probe failure and driver removal, as reducing that
>> limit to zero would interrupt ongoing power delivery.
>>
>> Boards without vmain-supply retain their existing firmware-managed
>> budget.
>>
>> Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
>> ---
>
> ...
>
>>   +static void rtpse_mcu_cleanup_vmain(void *data)
>> +{
>> +    struct rtpse_mcu_ctrl *pse = data;
>> +
>> +    if (pse->requested_budget_mW)
>> +        regulator_free_power_budget(pse->vmain, pse->requested_budget_mW);
>> +    regulator_disable(pse->vmain);
>> +}
>
> Following patch 4 logic, you might not want to disable the PSE controller power supply, 

I added it because of the requirement that regulator_enable() calls must be
balanced with regulator_disable() calls. Accepting that this may power off the
rail in theory, something outside of the driver would need to keep the supply
enabled. Concretely, I'm thinking of "regulator-always-on". And all boards
I've seen so far which can use this driver do not provide a provide to really
power off the PoE rail. Sure this is no finite guarantee.

What is the correct way? I see either droping the enable call too, just relying on
that it is correctly handled outside of this driver, or I keep enable + disable and
the continued delivery is ensured with "regulator-always-on".

> this will lead to a power off of all your PIs.

Is this enforced by PSE-PD or just based on the rail really being turned off?

> I think you should still free the power budget, to not allocate it twice if the module is loaded again.
>
> Else is ok to me.
>

Best,
Jonas