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)

---
Jonas Jelonek (2):
  dt-bindings: net: pse-pd: add bindings for Realtek/Broadcom PSE MCU
  net: pse-pd: add Realtek/Broadcom PSE MCU driver

 .../bindings/net/pse-pd/realtek,pse-mcu.yaml  |  154 +++
 MAINTAINERS                                   |    7 +
 drivers/net/pse-pd/Kconfig                    |   28 +
 drivers/net/pse-pd/Makefile                   |    3 +
 drivers/net/pse-pd/realtek-pse-core.c         | 1002 +++++++++++++++++
 drivers/net/pse-pd/realtek-pse-i2c.c          |  164 +++
 drivers/net/pse-pd/realtek-pse-uart.c         |  147 +++
 drivers/net/pse-pd/realtek-pse.h              |   70 ++
 8 files changed, 1575 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/pse-pd/realtek,pse-mcu.yaml
 create mode 100644 drivers/net/pse-pd/realtek-pse-core.c
 create mode 100644 drivers/net/pse-pd/realtek-pse-i2c.c
 create mode 100644 drivers/net/pse-pd/realtek-pse-uart.c
 create mode 100644 drivers/net/pse-pd/realtek-pse.h


base-commit: 903db046d5579bef0ea699eae4b279dd6455fc9f
-- 
2.51.0

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 |

Hi Oleksij,

On 11.06.26 13:03, Oleksij Rempel wrote:
> 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!

Thank you!

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

Yes, I'll have a look and address those issues in v2 soon.

> Best Regards,
> Oleksij

Best,
Jonas