Re: [PATCH net-next v14 0/4] net: pse-pd: add Realtek PSE MCU support

[Paolo Abeni <pabeni@redhat.com>]

On 8/14/26 12:20 AM, Jonas Jelonek wrote:
> This series adds a PSE-PD driver for the microcontroller (MCU) that
> fronts the PSE silicon on a range of managed switches, together with its
> DT binding.
> 
> Hardware model
> ==============
> 
> These boards do not expose the PSE chips to the host directly. A small
> microcontroller sits on an I2C/SMBus or UART bus and manages one or more
> PSE chips behind it; the host CPU only ever talks to that MCU, using a
> fixed 12-byte request/response protocol with a trailing checksum. The
> PSE silicon never appears on the bus.
> 
> Two generations of the protocol exist, both Realtek's: an older one on
> boards with Broadcom PSE silicon (BCM59111, BCM59121) and a newer one
> used with Realtek's own PSE silicon (RTL8238B, RTL8239, RTL8239C). They
> diverge in opcode numbering and a few response layouts; the driver
> abstracts that behind a per-dialect opcode table and parser hooks,
> selected by the compatible. The specific PSE chip behind the MCU is
> detected at runtime and only influences per-chip constants (power scaling
> and the per-port cap).
> 
> The compatibles
> ===============
> 
> The protocol compatibles name two generations of the Realtek protocol,
> with the I2C framing folded in:
> 
>   realtek,pse-mcu-gen1        gen1, UART
>   realtek,pse-mcu-gen1-smbus  gen1, I2C/SMBus
>   realtek,pse-mcu-gen2        gen2, UART
>   realtek,pse-mcu-gen2-smbus  gen2, I2C/SMBus
>   realtek,pse-mcu-gen2-i2c    gen2, raw I2C
> 
> and each board carries a device-specific compatible that falls back to one
> of these, e.g.
> 
>   compatible = "zyxel,xs1930-12hp-pse", "realtek,pse-mcu-gen2-smbus";
> 
> The naming is the part most likely to raise questions, so the reasoning up
> front (the binding documents it too):
> 
>   - The node describes the MCU together with its Realtek firmware, not a
>     PSE chip and not the microcontroller silicon. The PSE chips sit behind
>     the MCU, never appear on the bus, and are reported by the MCU and
>     detected at runtime; the microcontroller itself is a general-purpose
>     part (GigaDevice, Nuvoton, ...) that varies across boards. What is
>     fixed and Realtek's is the firmware and its host protocol - hence the
>     'realtek' prefix.
> 
>   - gen1 and gen2 are two generations of that protocol, both Realtek's:
>     gen1 on older boards fronting Broadcom PSE silicon, gen2 the altered
>     protocol used once Realtek shipped their own PSE silicon. The
>     generation is fixed per board and is all the driver needs at DT-parse
>     time, so the compatible encodes it.
> 
>   - On I2C the MCU firmware expects one of two framings - SMBus or raw
>     I2C - which is a genuine programming-model difference, so it is part
>     of the compatible ('-smbus' / '-i2c'). A UART attachment carries no
>     framing suffix; the transport is given structurally by the parent
>     'serial' node.
> 
>   - Each board additionally carries a device-specific compatible that
>     falls back to the protocol one. The driver only ever binds on the
>     protocol compatible; the device-specific string keeps the binding
>     specific and reserves a place for a future per-board quirk without
>     having to retrofit device trees already deployed in the field.
> 
> Testing
> =======
> 
>  - Linksys LGS328MPCv2     (RTL8238B, I2C)
>  - Zyxel GS1900-10HP A1    (BCM59121, UART)
>  - Zyxel GS1900-10HP B1    (RTL8238B, UART)
>  - Zyxel GS1920-24HPv2     (BCM59121, SMBus)
>  - Zyxel XMG1915-10EP      (RTL8239C, UART)
>  - Zyxel XS1930-12HP       (RTL8239, SMBus)
> 
Please note the the nipa sashiko instance as a few more low prio comments:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260813222036.873930-1-jelonek.jonas%40gmail.com

I think it's better to apply the series as-is and follow-up on such points.

Thanks,

Paolo