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

[Jonas Jelonek]

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