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

[Jonas Jelonek]

On 04.11.26 13:36, Kory Maincent wrote:
>
>
> On 11/4/26 13:20, Jonas Jelonek wrote:
>> 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@xxxxxxxxxxxxxxx>
>>>> ---
>>>
>>> ...
>>>
>>>>    +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".
>
> Indeed if you use "regulator-always-on" it does not turn off the power supply when we call regulator_disable().
> https://elixir.bootlin.com/linux/v7.3/source/drivers/regulator/core.c#L3269
>
> Does the PSE controller needs this supply to start, or is it only required to power the PSE PIs?
>
> If it is the first you will need to enable it in the driver.
> If it's the latter, you could describe it as the PI's regulator parent supply. An enable of any PI will enable this vmain regulator.
>

The purpose of this supply right now is to have the budget defined correctly
and let the driver apply it. The rail input and managing the budget globally
across all downstream managers and PIs is done in the firmware. The physical
rail on the board itself doesn't need explicit enabling, mostly because it really is
always-on. Potentially it might be used for more later, including referencing it
in vpwr-supply of PIs.

So having regulator_enable() here in the first place is probably not useful.

>>> 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?
>
> If you call regulator_disable() on the main PSE power supply it will turn off the power rail which will turn off you PIs.
>

Best,
Jonas