Re: [PATCH net-next v8 1/4] dt-bindings: net: pse-pd: add bindings for Realtek PSE MCU

Hi,

On 22.07.26 19:49, Sander Vanheule wrote:

[...]

quoted

+  power-supply:
+    description: Regulator supplying the PoE power rail.

As I reported to Jonas earlier [1], I used this property to define a power
supply for the 54V rail. While everything was working nicely, I still got this
warning for the missing vpwr-supply property on the PSE-PI nodes:

regulator regulator.2: supply vpwr not found, using dummy regulator
Of course I don't like seeing warnings when everything is seemingly working
fine, but I was also wondering if this duplicated way of providing the PoE power
rail is a good way to go forward and if the generic pse-pi@n/vpwr-supply
shouldn't just be used instead. The latter is admittedly more verbose, with a
property on every node, but going forward offers a few advantages IMHO:
 * Being able to reserve "power-supply" on the main node for the MCU's actual
   3.3V regulator (not needed anywhere at the moment AFAIK)

I would probably rename this, mirroring the PD692x0 naming. "power" is actually
too blurry, leaving too much room for interpretation. Still keeping its purpose
to reference the supply that serves the PoE rail for this MCU with its downstream
PSE. Reasoning below.

 * Being able to take advantage of the generic pse-pi framework evolving to take
   into account more properties of the parent regulator, such as requesting more
   power, or ensuring the parent supply is not overdrawn by the combined PSE-PI
   outputs.

Correct me if I'm wrong but from what I see, most of that budgeting machinery
isn't used in dynamic budget evaluation strategy, which is used here because the
MCU does budgeting on it's own. Using vpwr-supply on each PI still buys that the
supply is enabled and ref-counted by PSE-PD core, and keeps potential for what
might come. But no requesting, allocation or deallocation of power.

Given that, I had a closer look at PD692x0 and it seems, this has a similar setup.
The difference here being just that there's no multi-manager concept. There is
also a manager-level supply reference "vmain-supply" which the driver reads
and applies to the hardware, which does budgeting also in hardware.

Based on that, I would just adjust the binding to more suitable name for the
supply. Implementing the power budget application to the MCU is fine for a
follow-up. All boards I've worked with so far already have a pre-set safe budget
in their default configuration, avoiding any potential issues or physical damage
due to overload.

[1] https://github.com/openwrt/openwrt/pull/23222#issuecomment-5032841546

Best,
Sander

Best,
Jonas