[PATCH net-next v3 01/12] dt-bindings: net: airoha: Add EN7581 ethernet-ports properties

[Lorenzo Bianconi]

> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
> 
> This commit introduces the ethernet-port property to model a net_device
> connected via an external arbiter to the GDM3 or GDM4 ports on EN7581
> and AN7583 SoCs.
> 
> > diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > index fbe2ddcdd909c..ebbd433e9c9fb 100644
> > --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > @@ -130,6 +130,30 @@ patternProperties:
> >          maximum: 4
> >          description: GMAC port identifier
> >  
> > +      '#address-cells':
> > +        const: 1
> > +      '#size-cells':
> > +        const: 0
> > +
> > +    patternProperties:
> > +      "^ethernet-port@[0-5]$":
> 
> The commit message states that GDM1 and GDM2 do not support connection
> with the external arbiter. However, since this pattern property appears to
> be placed inside the generic ^ethernet@[1-4]$ block, does this allow a
> device tree to incorrectly configure ethernet-port subnodes on ethernet at 1
> or ethernet at 2 and still pass schema validation?

ack, I will fix it in v4

> 
> Could this be restricted to GDM3 and GDM4, perhaps by splitting the
> patternProperties or using an if/then block based on the reg property?
> 
> > +        type: object
> > +        unevaluatedProperties: false
> > +        $ref: ethernet-controller.yaml#
> 
> Does referencing ethernet-controller.yaml cause a validation conflict here?
> 
> The ethernet-controller.yaml schema enforces a strict nodename pattern
> of ^ethernet(@.*)?$. Since these new nodes use the -port suffix and are
> named ethernet-port at X, will they unconditionally fail the node name
> validation enforced by the referenced schema during dt_binding_check?

ack, I will fix it in v4

Regards,
Lorenzo

> 
> [ ... ]
> -- 
> pw-bot: cr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mediatek/attachments/20260410/d45139f8/attachment-0001.sig>