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

[Sander Vanheule <sander@svanheule.net>]

Hi,

On Wed, 2026-07-15 at 07:55 +0000, Jonas Jelonek wrote:
> Add a binding for the microcontroller (MCU) that fronts the PSE silicon
> on a range of managed Realtek-based switches. The host talks only to the
> MCU, over I2C/SMBus or UART, using a fixed message-based protocol; the
> PSE chips behind it never appear on the bus.
> 
> The device is the MCU together with its Realtek firmware: the firmware
> and its host protocol are what the binding describes, not the
> general-purpose microcontroller they run on. The PSE silicon behind the
> MCU (Realtek or Broadcom) is reported by the MCU and detected at runtime,
> so it is not described here - hence the 'realtek' vendor prefix.
> 
> Two protocol generations exist, both Realtek's, selected by the
> compatible: gen1 on older boards (fronting Broadcom PSE silicon) and gen2,
> the altered protocol used with Realtek's own PSE silicon. On an I2C
> attachment the framing the MCU firmware expects is part of the compatible
> as well - '-smbus' or raw '-i2c'; a UART attachment carries no framing
> suffix, as the transport is given by the parent serial node.
> 
> Each board additionally carries a device-specific compatible that falls
> back to one of the protocol compatibles above. Drivers bind on the
> protocol compatible; the device-specific string identifies the board and
> reserves a place for a future per-board quirk without having to retrofit
> device trees already in the field.
> 
> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
[...]

> +  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)
 * 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.

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

Best,
Sander