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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The schema's patternProperties regex `^ethernet-port@[0-8]$` is too restrictive, allowing node names like `port@X` to bypass switch-specific port constraints.
- [Medium] The binding enforces a fixed 2000ps internal delay and uses `phy-mode = "rgmii"` in the example, which explicitly violates the core Ethernet controller DT guidelines.
--

commit 8516a555bd26f4b1d70ac6a8947c1ce165b314b8
Author: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>

dt-bindings: net: lan9645x: add LAN9645X switch bindings

This commit adds device tree bindings for the LAN9645X multi-port Gigabit
AVB/TSN Ethernet switch. It uses 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 0000000000000..043fb48922b41
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
[ ... ]
> +  ethernet-ports:
> +    type: object
> +    patternProperties:
> +      "^ethernet-port@[0-8]$":

[Severity: Medium]
Will this restrictive pattern allow node names like port@X to bypass the
switch-specific port constraints defined here?

The base schema dsa.yaml allows switch ports to be named either port@X or
ethernet-port@X. By restricting this regex, a port@X node would be valid
under dsa.yaml but fail to match this block, bypassing the internal delay
constraints and the unevaluatedProperties check.

Could this be updated to "^(ethernet-)?port@[0-8]$" to match the base
schema?

> +        type: object
> +        description: Ethernet switch ports
> +
> +        $ref: dsa-port.yaml#
> +        unevaluatedProperties: false
> +
> +        properties:
> +          rx-internal-delay-ps:
> +            const: 2000
> +
> +          tx-internal-delay-ps:
> +            const: 2000

[Severity: Medium]
Does forcing these delays to a hardcoded 2000ps violate the core Ethernet
controller guidelines?

Enforcing a constant 2000 requires every device tree to include this as
redundant boilerplate. Typically, a full 2ns delay should be handled
implicitly by the driver when using an internal-delay phy-mode, using
explicit delay properties only for sub-nanosecond fine-tuning.

[ ... ]
> +            ethernet-port@7 {
> +                reg = <7>;
> +                phy-mode = "rgmii";
> +                ethernet = <&cpu_host_port>;
> +                rx-internal-delay-ps = <2000>;
> +                tx-internal-delay-ps = <2000>;

[Severity: Medium]
Is this example combining phy-mode = "rgmii" with 2000ps internal MAC
delays allowed by the networking device tree guidelines?

The ethernet-controller.yaml explicitly rejects this pattern, stating that
a value of 2000ps and a phy-mode of "rgmii" is invalid. If the MAC provides
the full 2ns delay, the interface is functionally operating in an
internal-delay mode, and phy-mode = "rgmii-id" should be used instead.

> +
> +                fixed-link {
> +                    speed = <1000>;
> +                    full-duplex;
> +                    pause;
> +                };
> +            };
> +        };
> +    };
> +...

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603-dsa_lan9645x_switch_driver_base-v7-0-b2f90e676707@microchip.com?part=2