Re: [PATCH net-next v5 1/4] dt-bindings: net: pse-pd: add bindings for Realtek/Broadcom PSE MCU

[Jonas Jelonek <jelonek.jonas@gmail.com>]

Hi Conor,

On 08.07.26 18:56, Conor Dooley wrote:
> On Tue, Jul 07, 2026 at 10:50:21PM +0200, Jonas Jelonek wrote:
>> [...]
>> Ok, I hope I put this together correctly. A concrete proposal:
>>
>> "realtek,pse-mcu-gen1"                        (Protocol Gen 1, UART)
>> "realtek,pse-mcu-gen1-smbus"            (Protocol Gen 1, SMBus)
>> "realtek,pse-mcu-gen2"                        (Protocol Gen 2, UART)
>> "realtek,pse-mcu-gen2-i2c"                  (Protocol Gen 2, raw I2C)
>> "realtek,pse-mcu-gen2-smbus"            (Protocol Gen 2, SMBus)
>>
>> This uniquely identifies the protocol used: first generation and second
>> generation. As Rob mentioned before [1], this also pulls in the raw I2C
>> vs. SMBus framing in contrast to having it in a property. The framing
>> suffix appears only on I2C attachments because it doesn't apply to
>> UART transport, and this is given by the parent serial@ node.
>>
>> Though I'm still open for suggestions regarding the protocol
>> identification if "-gen1"/"-gen2" is not acceptable.
> This seems reasonable enough.
>
>> [...]
>>
>> It would also be an exception to the other PSE-PD bindings. They describe
>> controllers used across many switches too, yet none encode the
> The difference is those cases (for what few pse-psd bindings there are)
> the compatibles correspond to individual devices. Here you have
> compatibles you're going to use to cover multiple devices (with device
> corresponding to a combination of mcu/firmware/hardware behind the mcu).
> That lack of a 1:1 mapping is why I'm asking for something different from
> you than you see with the existing pse-pd devices. The switch the device
> is integrated on seems to be the only thing that reasonably makes sense
> to use.
>
>
>> switch/enclosure. Board-specific compatibles might still be added later in
>> case a device really has a variation or quirk that genuinely needs its own
>> compatible.
> And in doing so, have to retrofit that compatible to all devicetrees
> that use it. This is one of the reasons that we generally demand
> device-specific compatibles.
>
> You could add switch-specific compatibles that fall back to the ones you
> provide above, with the driver only using the ones above unless
> something crops up in the future?

Thank you for the thorough explanation. I think I got your point now and
understand why it's required that way.

I'll rework this for the next version.

> Cheers,
> Conor.

Best regards,
Jonas