> 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@1 > or ethernet@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@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