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

[Sander Vanheule <sander@svanheule.net>]

Hi Kory,

On Wed, 2026-11-04 at 13:36 +0100, 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@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".
> 
> 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.

I'm not sure if you've seen a diagram before, but allow me to add one to show
what the binding currently models (for a UART controlled MCU):

              ▲Vdd     ▲Vpwr                          
        ┌─────┼────────┼─────────────────┐            
        │     ├────────┼───────┬───┐     │            
        │  ┌──┴────┐   │       │┌──┴───┐ │            
      ──┼─►┤RX  SDA├───┼────┬──┼┤      ├─┼───► PSE-PI0
      ◄─┼-─┤TX  SCL├───┼───┬┼──┼┤      ├─┼───► PSE-PI1
        │  │       │   │   ││  ││      ├─┼───► PSE-PI2
        │  │MCU    │   ├───┼┼──┼┤PSE-0 ├─┼───► PSE-PI3
        │  └───────┘   │   ││  │└──────┘ │            
        │              │   ││  └───┐     │            
        │              │   ││   ┌──┴───┐ │            
        │              │   │└───┤      ├─┼───► PSE-PI4
        │              │   └────┤      ├─┼───► PSE-PI5
        │              │        │      ├─┼───► PSE-PI6
        │              └────────┤PSE-1 ├─┼───► PSE-PI7
        │realtek,pse-mcu-gen1   └──────┘ │            
        └────────────────────────────────┘            


The outer box is what is modeled by the binding, but really consists of at least
two chips on the board. The "vpwr-supply" (Vpwr) of the PSE PIs is controlled by
the PSE-n ICs. The MCU doesn't use Vpwr and doesn't control it directly, but has
to do this via the PSE controllers. This is similar to a PD69200 setup.

Like Jonas said, Vpwr is usually (always) an always-on power supply, which
matches well with "regulator-always-on". Vdd is the supply that actually powers
the logic, but that is normally also not a switchable supply and hence not
modeled by the devicetrees describing these PoE switches.

This proposal adds Vpwr as "vmain-supply" on the main DT node, but I suppose
that also means it should not be used for "vpwr-supply" on the PI subnodes?

Would it make sense to model realtek,pse-mcu as a regulator as well and have
"vpwr-supply" PI properties point there (instead of the fixed regulator)?
AFAICT that's similar to the approach taken by the microchip,pd692x0 binding,
where the PI nodes point to a manager. But I also don't know if that offers any
advantages here.

Best,
Sander