Add bindings for LAN9645X switch. We use a fallback compatible for the
smallest SKU microchip,lan96455s-switch.
Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
---
Changes in v2:
- rename file to microchip,lan96455s-switch.yaml
- remove led vendor property
- add {rx,tx}-internal-delay-ps for rgmii delay
- remove labels from example
- remove container node from example
---
.../net/dsa/microchip,lan96455s-switch.yaml | 119 +++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 120 insertions(+)
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
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/microchip,lan96455s-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip LAN9645x Ethernet switch
+
+maintainers:
+ - Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
+
+description: |
+ The LAN9645x switch is a multi-port Gigabit AVB/TSN Ethernet switch with
+ five integrated 10/100/1000Base-T PHYs. In addition to the integrated PHYs,
+ it supports up to 2 RGMII/RMII, up to 2 BASE-X/SERDES/2.5GBASE-X and one
+ Quad-SGMII interfaces.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - microchip,lan96455s-switch
+ - items:
+ - enum:
+ - microchip,lan96455f-switch
+ - microchip,lan96457f-switch
+ - microchip,lan96459f-switch
+ - microchip,lan96457s-switch
+ - microchip,lan96459s-switch
+ - const: microchip,lan96455s-switch
+
+ reg:
+ maxItems: 1
+
+$ref: dsa.yaml#
+
+patternProperties:
+ "^(ethernet-)?ports$":
+ type: object
+ additionalProperties: true
+ patternProperties:
+ "^(ethernet-)?port@[0-8]$":
+ type: object
+ description: Ethernet switch ports
+
+ $ref: dsa-port.yaml#
+
+ properties:
+ rx-internal-delay-ps:
+ const: 2000
+
+ tx-internal-delay-ps:
+ const: 2000
+
+ unevaluatedProperties: false
+
+oneOf:
+ - required:
+ - ports
+ - required:
+ - ethernet-ports
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet-switch@4000 {
+ compatible = "microchip,lan96459f-switch", "microchip,lan96455s-switch";
+ reg = <0x4000 0x244>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ phy-mode = "gmii";
+ phy-handle = <&cuphy0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ phy-mode = "gmii";
+ phy-handle = <&cuphy1>;
+ };
+
+ port@2 {
+ reg = <2>;
+ phy-mode = "gmii";
+ phy-handle = <&cuphy2>;
+ };
+
+ port@3 {
+ reg = <3>;
+ phy-mode = "gmii";
+ phy-handle = <&cuphy3>;
+ };
+
+ port@7 {
+ reg = <7>;
+ phy-mode = "rgmii";
+ ethernet = <&cpu_host_port>;
+ rx-internal-delay-ps = <2000>;
+ tx-internal-delay-ps = <2000>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+ };
+...
+
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ae698067c41..8232da1b3951 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17278,6 +17278,7 @@ M: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
M: UNGLinuxDriver@microchip.com
L: netdev@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
F: include/linux/dsa/lan9645x.h
F: net/dsa/tag_lan9645x.c
--
2.52.0
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? > + 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. [ ... ] > +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#?
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.
© 2016 - 2026 Red Hat, Inc.