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

[Oleksij Rempel <o.rempel@pengutronix.de>]

Hi Jonas,

On Mon, Jun 08, 2026 at 08:57:55PM +0000, 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.
> 
> The same protocol family is used by MCUs fronting Realtek PSE chips
> (RTL8238B, RTL8239, RTL8239C) and Broadcom PSE chips (BCM59111, BCM59121),
> diverging 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).
> 
> Why the compatible names the protocol, not the chip
> ===================================================
> 
> The compatibles are "realtek,pse-mcu-rtk" and "realtek,pse-mcu-bcm". This is
> a deliberate choice and the part most likely to raise questions, so the
> reasoning up front.
> 
> The node names the protocol dialect, not a part:
> 
>   - The DT node describes the MCU, not a PSE chip: the PSE chips are behind
>     the MCU and never appear on the bus, so naming the node after one (e.g.
>     "realtek,rtl8239") would describe hardware that isn't at that address.
> 
>   - The PSE chips are, in principle, usable without this MCU (host-driven
>     directly) - different hardware with a different programming model that
>     would warrant its own binding. Claiming the PSE-chip compatibles here
>     would collide with that.
> 
>   - Naming the MCU silicon is equally wrong: these are ordinary
>     general-purpose microcontrollers (GigaDevice, Nuvoton, ...) that vary
>     across boards and are not dedicated to this application.
> 
>   - What is fixed, and all the driver needs at DT-parse time, is the
>     protocol dialect, so the compatible encodes exactly that. The two
>     dialects share one protocol family and one binding, kept in a single
>     "realtek" vendor namespace because this MCU front-end is found almost
>     exclusively on Realtek-based switches; a "-rtk"/"-bcm" suffix selects
>     the dialect. This follows the "google,cros-ec-*" pattern: a compatible
>     for a firmware/protocol interface implemented by varying
>     microcontrollers.
> 
> One compatible per dialect spans both transports:
> 
>   - The 12-byte wire protocol is identical over I2C/SMBus and UART; only the
>     plumbing differs (SMBus vs native framing on I2C, baud rate on UART),
>     and the transport is already expressed structurally by the node's parent
>     bus (i2c@... vs serial@...). A "-i2c"/"-uart" suffix would only
>     duplicate that, for a protocol that does not change across transports.
> 
>   - This is the multi-transport model used by e.g. "bosch,bmi160" (one
>     compatible, separate i2c and spi drivers binding it), rather than the
>     cros-ec model of per-transport compatibles - cros-ec splits because its
>     on-wire framing genuinely differs per bus, which is not the case here.
> 
> The binding documents both points as well.
> 
> Testing
> =======
> 
>  - Linksys LGS328MPCv2  (RTL8238B, I2C)
>  - Zyxel GS1900-10HP A1 (BCM59121, UART)
>  - Zyxel GS1900-10HP B1 (RTL8238B, UART)
>  - Zyxel XMG1915-10EP   (RTL8239C, UART)
>  - Zyxel XS1930-12HP    (RTL8239, SMBus)
> 
 
Thank you for your work!

Overall, LGTM. Can you please take a look at this report:
https://sashiko.dev/#/patchset/20260608205758.1830521-1-jelonek.jonas%40gmail.com 

kzalloc_obj - seems to be a false positive. Some other have good points.

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |