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

Hi Conor,

On 06.07.26 19:35, Conor Dooley wrote:

quoted

On Mon, Jul 06, 2026 at 11:24:21AM +0000, Jonas Jelonek wrote:

quoted

[...]
+
+description: |
+  Microcontroller (MCU) that fronts the PSE hardware on switches using
+  Realtek (RTL8238B, RTL8239, RTL8239C) or Broadcom (BCM59111, BCM59121)
+  PSE chips. The MCU exposes a small message-based protocol over either
+  I2C/SMBus or UART; the actual PSE silicon is not accessed directly. The
+  Realtek and Broadcom variants share this device tree contract but use
+  different protocol opcodes, selected by the compatible.
+
+  The compatible identifies the PSE-MCU protocol dialect, not a specific
+  part. The device here is the MCU: it presents a stable message protocol
+  documented by Realtek, with the PSE silicon behind it - Broadcom on
+  older boards, Realtek on newer - detected at runtime and not described
+  here. The MCU's own silicon is general-purpose and varies across
+  boards, so the 'realtek' vendor prefix names the protocol front-end
+  (following the google,cros-ec pattern); the '-rtk'/'-brcm' suffix
+  selects the Realtek or Broadcom dialect.
+
+  A single compatible per dialect covers both the I2C/SMBus and UART
+  attachments: the wire protocol is identical across them and the
+  transport is already expressed by the node's parent bus, so it is not
+  encoded in the compatible. Transport-specific properties differ
+  accordingly - the I2C attachment carries 'reg' (and, for Realtek,
+  'realtek,i2c-protocol'), while the UART attachment carries the serial
+  peripheral properties such as 'current-speed'.

I'm not really convinced by the arguments here.

If the switch vendors are running different software on their MCUs to
the point that they behave differently, then yes it makes sense to have
different compatibles.

The first thing I don't understand is why realtek is considered the
main vendor here? Is it their MCU that broadcom are re-using with some
protocol tweaks?

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

If it is, then having the vendor as a suffix like wheel reinvention to
me, and if the MCU and/or protocol aren't something that broadcom
borrowed from realtek then having a realtek vendor prefix is strange
altogether. The mention of old boards being broadcom while the protocol
is documented by realtek is confusing me.

Either way, encoding the vendor without using the vendor prefix seems
very odd me to.

I'm open for suggestions here. This has been the hardest issue in this
whole series, to be honest. It basically boils down to differentiating
these two protocol generations. I cannot say why Realtek did that on
the transition to their own PSE silicon but vendors doing weird stuff
shouldn't be surprising and this is the reality now.

Is something like "-gen1" and "-gen2" better, with a clear description
somewhere in the bindings how that maps to actual device setups
(gen1 = older/MCU fronts Broadcom PSE, gen2 = newer/MCU fronts
Realtek PSE)? This would drop Broadcom and the confusion around it
here. I admit, using a vendor suffix isn't great and still attributes
Broadcom too much in this context here.

quoted

Secondly, the compatibles you do provide seem too generic. Is it really
possible for a given board to use smbus AND i2c, or do specific boards
only ever use i2c OR smbus (or uart for that matter).
I find it more believable that a board would support i2c and uart than
supporting both i2c and smbus fwiw.

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. 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.

quoted

Can you provide a link to the actual devices somewhere? It is
completely non-obvious to me what the binding actually represents.

I hope I get your request correctly. Find some links to devices and/or

Ye, this is what I was looking for, thanks.

Conor.

to my commits wiring that up in actual DTS (WIP, hashes may change).

Zyxel XMG1915-10EP (UART with Realtek PSE silicon):
https://svanheule.net/switches/xmg1915-10ep
https://github.com/jonasjelonek/openwrt/commit/d173e64730a511e04b68271289be23ae4e98a02f

Zyxel XS1930-12HP (SMBus with Realtek PSE silicon):
https://www.zyxel.com/de/de/products/switch/10-12-port-10g-multi-gigabit-lite-l3-smart-managed-switch-xs1930-series
https://github.com/jonasjelonek/openwrt/commit/74339c9a002032fc204b6b1fe07af259d8f51787

Zyxel GS1900-10HPv1 (UART with Broadcom PSE silicon):
https://svanheule.net/switches/gs1900-10hp

Linksys LGS328MPC (I2C raw, not SMBus, with Realtek PSE silicon):
https://support.linksys.com/kb/article/5133-en/

(mostly Zyxel devices but that's just the main devices I work with)

quoted

Cheers,
Conor.

quoted

[...]

Best regards,
Jonas