Hi Conor,

On 07.07.26 19:25, Conor Dooley wrote:

On Mon, Jul 06, 2026 at 10:30:00PM +0200, Jonas Jelonek wrote:

quoted

[...]
The protocol and firmware on the MCU, most likely the whole "solution",
is from Realtek. The setup is always the same on most Realtek-based
switches (saying most because a few counterexamples use completely
different setups, not even Broadcom or Realtek PSE silicon). The host
interface is always the same (except for I2C vs. SMBus vs. UART, which
is likely just a config in the MCU firmware). Therefore "realtek," is the
right prefix for all of these.

Broadcom is not really involved here except for their PSE silicon being
used. Maybe Realtek modeled their MCU host protocol after the one that
Broadcom PSE silicon uses as host interface, but this is rather guessing.

Maybe a historical view might help. Older RTL83xx-based switches with
PoE shipped with this setup using Broadcom PSE silicon. From what I know,
at this point Realtek didn't design their own PSE silicon. They used the
Broadcom silicon, put a MCU as a manager in front of it with their firmware
and a host protocol based on what Broadcom PSE itself uses. At some
point Realtek started to design their own PSE silicon which then was
used in newer switches instead of Broadcom PSE.

Right, in that case it does make sense to use a realtek prefix, since
the software and mcu solution is all theirs.

quoted

[...]
Only one at a time is used, but not combined in any way. All switches
I've seen so far always have a single management MCU for PoE, not
multiple. Thus, only a single variant is used. Which variant is used
likely depends on the board vendor which then tells Realtek "I want your
PoE solution, I can attach it via (I2C/SMBus/UART)". At least for UART vs.
I2C/SMBus there are sometimes valid reasons to use UART over the other.

There is only a single switch (from Linksys) where the MCU expects raw
I2C messages. SMBus transaction fail actually. But I don't see the reason
why Linksys did it that way. The reason can't be that the MCU is attached
on a bit-banged I2C because another switch uses SMBus transaction on
a bit-banged I2C.

Reading this, it feels like you "should" have compatibles that uniquely
identify the protocol used. 

Ok, I hope I put this together correctly. A concrete proposal:

"realtek,pse-mcu-gen1"                        (Protocol Gen 1, UART)
"realtek,pse-mcu-gen1-smbus"            (Protocol Gen 1, SMBus)
"realtek,pse-mcu-gen2"                        (Protocol Gen 2, UART)
"realtek,pse-mcu-gen2-i2c"                  (Protocol Gen 2, raw I2C)
"realtek,pse-mcu-gen2-smbus"            (Protocol Gen 2, SMBus)

This uniquely identifies the protocol used: first generation and second
generation. As Rob mentioned before [1], this also pulls in the raw I2C
vs. SMBus framing in contrast to having it in a property. The framing
suffix appears only on I2C attachments because it doesn't apply to
UART transport, and this is given by the parent serial@ node.

Though I'm still open for suggestions regarding the protocol
identification if "-gen1"/"-gen2" is not acceptable.

Looking at the devices below, it seems like it
would be possible to use compatibles based on the switches themselves, e.g.
zyxel,xs1930-pse etc. If there are other devices that use the same
protocol, they could fall back to the ones below.

It'd be good to have the net developers weigh in though, as to whether
using compatibles based on the switches is suitable.

I'd lean against, but happy to defer to you and the net maintainers. The
node describes the MCU with its Realtek firmware — the firmware/protocol
defines the device. Everything that differs between instances on the
controller level would be captured by the compatibles proposed above, so
a board compatible would encode nothing there the gen+framing string
doesn't.

Observed variation lives on another level. For instance, some boards have
heterogeneous per-port caps (e.g. 16 ports at 60W, 8 ports at 30W). This
is clearly something that should be expressed per-pse-pi, not in a
switch-specific compatible.

It would also be an exception to the other PSE-PD bindings. They describe
controllers used across many switches too, yet none encode the
switch/enclosure. Board-specific compatibles might still be added later in
case a device really has a variation or quirk that genuinely needs its own
compatible.

[...]

Best regards,
Jonas


[1] https://lore.kernel.org/netdev/20260615212959.GA1679454-robh@kernel.org/ (local)