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

[Jonas Jelonek]

Hi Rob,

On 15.06.26 23:29, Rob Herring wrote:
> On Fri, Jun 12, 2026 at 01:29:41PM +0000, Jonas Jelonek wrote:
>> [...]
>>
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - realtek,pse-mcu-rtk
> The "rtk" feels redundant.

In the full Realtek case yes. Do you have a suggestion to improve
that?

>> +      - realtek,pse-mcu-bcm
> "brcm" is the standard vendor prefix, so use that instead of "bcm". 
> Though who defined the protocol in this case? Realtek or Broadcom? In 
> the latter case, I'd argue that "brcm" should be the vendor prefix.

I'll switch to brcm.
As Daniel already mentioned, Realtek defines the firmware and thus
the protocol, in both cases.

>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  power-supply:
>> +    description: Regulator supplying the PoE power rail.
>> +
>> +  enable-gpios:
>> +    maxItems: 1
>> +
>> +  realtek,i2c-protocol:
>> +    $ref: /schemas/types.yaml#/definitions/string
>> +    enum: [ i2c, smbus ]
>> +    description: |
>> +      Wire framing the MCU firmware expects on the I2C bus. "smbus" means
>> +      reads carry a leading command byte (0x00) and a repeated start; "i2c"
>> +      means bare 12-byte writes and reads with no command prefix. Only
>> +      applies to the Realtek I2C attachment.
> I tend to think this should be distinguished by the compatible string. 
> That would simplify the schema given it only applies to one of the 
> compatible strings.

In theory this could also apply to the Broadcom dialect, however I didn't
have a device with that variant on my desk.

If you would go with separate compatibles, do you thought about
something like "realtek,pse-mcu-rtk-i2c" and
"realtek,pse-mcu-rtk-smbus" (given we stick with rtk) ?

> Rob

Best regards,
Jonas