Re: [PATCH net-next v2 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings

[Jens Emil Schulz Ostergaard]

On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> dt-bindings: net: lan9645x: add LAN9645X switch bindings
> 
> Add bindings for LAN9645X switch. We use a fallback compatible for the
> smallest SKU microchip,lan96455s-switch.
> 
> > diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > new file mode 100644
> > index 000000000000..0282e25c05d4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> 
> [ ... ]
> 
> > +patternProperties:
> > +  "^(ethernet-)?ports$":
> > +    type: object
> > +    additionalProperties: true
> > +    patternProperties:
> > +      "^(ethernet-)?port@[0-8]$":
> 
> Does having additionalProperties set to true bypass the port number
> restriction?
> 
> Since dsa.yaml allows port@[0-9a-f]+, it seems port@9 would silently pass
> validation as an additional property. Should this be unevaluatedProperties
> set to false instead?
> 

Yes it is true the port regex has no effect, but I do not think

unevaluatedProperties: false

is what I want here. That rejects other properties from the parent. I can
remove the explicit additionalProperties: true. This is similar to

Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml

and the port number restriction still serves as documentation, even if it is
not applied during validation.


> > +        type: object
> > +        description: Ethernet switch ports
> > +
> > +        $ref: dsa-port.yaml#
> > +
> > +        properties:
> > +          rx-internal-delay-ps:
> > +            const: 2000
> > +
> > +          tx-internal-delay-ps:
> > +            const: 2000
> 
> Does enforcing a 2000ps delay conflict with standard rgmii bindings?
> 
> As documented in net/ethernet-controller.yaml, a full 2ns delay is
> typically modeled using phy-mode set to rgmii-id rather than hardcoding the
> delay properties with a base rgmii mode.
> 

No this was explicitly requested on v1 to enable adding a delay with mac2mac links.
I enforce 2000ps because that is the only supported value.

> [ ... ]
> 
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +unevaluatedProperties: false
> 
> How are the five integrated 10/100/1000Base-T phys mentioned in the
> description modeled?
> 
> Since unevaluatedProperties is false at the top level and there is no
> definition or reference for an mdio node, wouldn't adding an mdio subnode
> to configure these phys fail schema validation?
> 
> Should there be a reference to /schemas/net/mdio.yaml#?

No, the MDIO busses will be part of a parent MFD device node, not the switch node.