| Message ID | 20231024-marvell-88e6152-wan-led-v7-0-2869347697d1@linaro.org |
|---|---|
| Headers | show |
| Series | Create a binding for the Marvell MV88E6xxx DSA switches | expand |
On 10/24/23 06:20, Linus Walleij wrote: > Fix some errors in the Marvell MV88E6xxx switch descriptions: > - The top node had no address size or cells. > - switch0@0 is not OK, should be ethernet-switch@0. > - The ports node should be named ethernet-ports > - The ethernet-ports node should have port@0 etc children, no > plural "ports" in the children. > - Ports should be named ethernet-port@0 etc > - PHYs should be named ethernet-phy@0 etc > > This serves as an example of fixes needed for introducing a > schema for the bindings, but the patch can simply be applied. > > Reviewed-by: Andrew Lunn <andrew@lunn.ch> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
On 10/24/23 06:20, Linus Walleij wrote: > Fix some errors in the Marvell MV88E6xxx switch descriptions: > - switch0@0 is not OK, should be ethernet-switch@0 > - ports should be ethernet-ports > - port should be ethernet-port > - phy should be ethernet-phy > > Reviewed-by: Andrew Lunn <andrew@lunn.ch> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
On 10/24/23 06:20, Linus Walleij wrote: > Fix some errors in the Marvell MV88E6xxx switch descriptions: > - The top node had no address size or cells. > - switch0@0 is not OK, should be ethernet-switch@0. > - ports should be ethernet-ports > - port@0 should be ethernet-port@0 > - PHYs should be named ethernet-phy@ > > Reviewed-by: Andrew Lunn <andrew@lunn.ch> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Linus, On Tue, Oct 24, 2023 at 03:20:31PM +0200, Linus Walleij wrote: > Fix some errors in the Marvell MV88E6xxx switch descriptions: > - The top node had no address size or cells. > - switch0@0 is not OK, should be ethernet-switch@0. > - ports should be ethernet-ports > - port@0 should be ethernet-port@0 > - PHYs should be named ethernet-phy@ > > Reviewed-by: Andrew Lunn <andrew@lunn.ch> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> > --- > .../dts/marvell/armada-3720-espressobin-ultra.dts | 14 +- > .../boot/dts/marvell/armada-3720-espressobin.dtsi | 20 +-- > .../boot/dts/marvell/armada-3720-gl-mv1000.dts | 20 +-- > .../boot/dts/marvell/armada-3720-turris-mox.dts | 189 +++++++++++---------- > .../boot/dts/marvell/armada-7040-mochabin.dts | 24 ++- > .../dts/marvell/armada-8040-clearfog-gt-8k.dts | 22 +-- > arch/arm64/boot/dts/marvell/cn9130-crb.dtsi | 42 +++-- > 7 files changed, 164 insertions(+), 167 deletions(-) > > diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts > index f9abef8dcc94..870bb380a40a 100644 > --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts > +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts > @@ -126,32 +126,32 @@ &switch0 { > > reset-gpios = <&gpiosb 23 GPIO_ACTIVE_LOW>; > > - ports { > - switch0port1: port@1 { > + ethernet-ports { > + switch0port1: ethernet-port@1 { > reg = <1>; > label = "lan0"; > phy-handle = <&switch0phy0>; > }; > > - switch0port2: port@2 { > + switch0port2: ethernet-port@2 { > reg = <2>; > label = "lan1"; > phy-handle = <&switch0phy1>; > }; > > - switch0port3: port@3 { > + switch0port3: ethernet-port@3 { > reg = <3>; > label = "lan2"; > phy-handle = <&switch0phy2>; > }; > > - switch0port4: port@4 { > + switch0port4: ethernet-port@4 { > reg = <4>; > label = "lan3"; > phy-handle = <&switch0phy3>; > }; > > - switch0port5: port@5 { > + switch0port5: ethernet-port@5 { > reg = <5>; > label = "wan"; > phy-handle = <&extphy>; > @@ -160,7 +160,7 @@ switch0port5: port@5 { > }; > > mdio { > - switch0phy3: switch0phy3@14 { > + switch0phy3: ethernet-phy@14 { > reg = <0x14>; > }; > }; > diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi > index 5fc613d24151..86ec0df1c676 100644 > --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi > +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi > @@ -145,19 +145,17 @@ &usb2 { > }; > > &mdio { > - switch0: switch0@1 { > + switch0: ethernet-switch@1 { > compatible = "marvell,mv88e6085"; > - #address-cells = <1>; > - #size-cells = <0>; > reg = <1>; > > dsa,member = <0 0>; > > - ports { > + ethernet-ports { > #address-cells = <1>; > #size-cells = <0>; > > - switch0port0: port@0 { > + switch0port0: ethernet-port@0 { > reg = <0>; > label = "cpu"; > ethernet = <ð0>; > @@ -168,19 +166,19 @@ fixed-link { > }; > }; > > - switch0port1: port@1 { > + switch0port1: ethernet-port@1 { > reg = <1>; > label = "wan"; > phy-handle = <&switch0phy0>; > }; > > - switch0port2: port@2 { > + switch0port2: ethernet-port@2 { > reg = <2>; > label = "lan0"; > phy-handle = <&switch0phy1>; > }; > > - switch0port3: port@3 { > + switch0port3: ethernet-port@3 { > reg = <3>; > label = "lan1"; > phy-handle = <&switch0phy2>; > @@ -192,13 +190,13 @@ mdio { > #address-cells = <1>; > #size-cells = <0>; > > - switch0phy0: switch0phy0@11 { > + switch0phy0: ethernet-phy@11 { > reg = <0x11>; > }; > - switch0phy1: switch0phy1@12 { > + switch0phy1: ethernet-phy@12 { > reg = <0x12>; > }; > - switch0phy2: switch0phy2@13 { > + switch0phy2: ethernet-phy@13 { > reg = <0x13>; > }; > }; I looked at U-Boot's ft_board_setup() from board/Marvell/mvebu_armada-37xx/board.c and it doesn't appear to do anything with the switch. But after the MOX precedent (which is _still_ problematic, more below), I still think we are way too trigger-happy with this, and it would be good to ask someone who has the Espressobin to test. Pali, you are the last committer on the Linux DTS, could you please boot-test this change, or at least confirm that as far as you know, there are no bootloader dependencies on the precise node name for the switch and its child nodes? > diff --git a/arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts b/arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts > index b1b45b4fa9d4..63fbc8352161 100644 > --- a/arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts > +++ b/arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts > @@ -152,31 +152,29 @@ &uart0 { > }; > > &mdio { > - switch0: switch0@1 { > + switch0: ethernet-switch@1 { > compatible = "marvell,mv88e6085"; > - #address-cells = <1>; > - #size-cells = <0>; > reg = <1>; > > dsa,member = <0 0>; > > - ports: ports { > + ports: ethernet-ports { > #address-cells = <1>; > #size-cells = <0>; > > - port@0 { > + ethernet-port@0 { > reg = <0>; > label = "cpu"; > ethernet = <ð0>; > }; > > - port@1 { > + ethernet-port@1 { > reg = <1>; > label = "wan"; > phy-handle = <&switch0phy0>; > }; > > - port@2 { > + ethernet-port@2 { > reg = <2>; > label = "lan0"; > phy-handle = <&switch0phy1>; > @@ -185,7 +183,7 @@ port@2 { > nvmem-cell-names = "mac-address"; > }; > > - port@3 { > + ethernet-port@3 { > reg = <3>; > label = "lan1"; > phy-handle = <&switch0phy2>; > @@ -199,13 +197,13 @@ mdio { > #address-cells = <1>; > #size-cells = <0>; > > - switch0phy0: switch0phy0@11 { > + switch0phy0: ethernet-phy@11 { > reg = <0x11>; > }; > - switch0phy1: switch0phy1@12 { > + switch0phy1: ethernet-phy@12 { > reg = <0x12>; > }; > - switch0phy2: switch0phy2@13 { > + switch0phy2: ethernet-phy@13 { > reg = <0x13>; > }; > }; Enrico, I see the GL-MV1000 device tree submission is relatively new. Could you please ACK this change as well? > diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts > index 9eab2bb22134..cdf1b8bdb230 100644 > --- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts > +++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts > @@ -304,7 +304,12 @@ phy1: ethernet-phy@1 { > reg = <1>; > }; > > - /* switch nodes are enabled by U-Boot if modules are present */ > + /* > + * NOTE: switch nodes are enabled by U-Boot if modules are present > + * DO NOT change this node name (switch0@10) even if it is not following > + * conventions! Deployed U-Boot binaries are explicitly looking for > + * this node in order to augment the device tree! > + */ Not "this node", but all switch nodes! > switch0@10 { > compatible = "marvell,mv88e6190"; > reg = <0x10>; > @@ -317,92 +322,92 @@ mdio { > #address-cells = <1>; > #size-cells = <0>; > > - switch0phy1: switch0phy1@1 { > + switch0phy1: ethernet-phy@1 { > reg = <0x1>; > }; > > - switch0phy2: switch0phy2@2 { > + switch0phy2: ethernet-phy@2 { > reg = <0x2>; > }; > > - switch0phy3: switch0phy3@3 { > + switch0phy3: ethernet-phy@3 { > reg = <0x3>; > }; > > - switch0phy4: switch0phy4@4 { > + switch0phy4: ethernet-phy@4 { > reg = <0x4>; > }; > > - switch0phy5: switch0phy5@5 { > + switch0phy5: ethernet-phy@5 { > reg = <0x5>; > }; > > - switch0phy6: switch0phy6@6 { > + switch0phy6: ethernet-phy@6 { > reg = <0x6>; > }; > > - switch0phy7: switch0phy7@7 { > + switch0phy7: ethernet-phy@7 { > reg = <0x7>; > }; > > - switch0phy8: switch0phy8@8 { > + switch0phy8: ethernet-phy@8 { > reg = <0x8>; > }; > }; > > - ports { > + ethernet-ports { U-Boot code does this, so you can't rename "ports": /* * now if there are more switches or a SFP module coming after, * enable corresponding ports */ if (id < peridot + topaz - 1) { res = fdt_status_okay_by_pathf(blob, "%s/switch%i@%x/ports/port@a", mdio_path, id, addr); } else if (id == peridot - 1 && !topaz && sfp) { res = fdt_status_okay_by_pathf(blob, "%s/switch%i@%x/ports/port-sfp@a", mdio_path, id, addr); } else { res = 0; } > #address-cells = <1>; > #size-cells = <0>; > > - port@1 { > + ethernet-port@1 { or "port@.*", or "port-sfp@a", for the same reason. Here and everywhere in this device tree. Basically only the ethernet-phy rename seems safe. > reg = <0x1>; > label = "lan1"; > phy-handle = <&switch0phy1>; > }; > > - port@2 { > + ethernet-port@2 { > reg = <0x2>; > label = "lan2"; > phy-handle = <&switch0phy2>; > }; > > - port@3 { > + ethernet-port@3 { > reg = <0x3>; > label = "lan3"; > phy-handle = <&switch0phy3>; > }; > > - port@4 { > + ethernet-port@4 { > reg = <0x4>; > label = "lan4"; > phy-handle = <&switch0phy4>; > }; > > - port@5 { > + ethernet-port@5 { > reg = <0x5>; > label = "lan5"; > phy-handle = <&switch0phy5>; > }; > > - port@6 { > + ethernet-port@6 { > reg = <0x6>; > label = "lan6"; > phy-handle = <&switch0phy6>; > }; > > - port@7 { > + ethernet-port@7 { > reg = <0x7>; > label = "lan7"; > phy-handle = <&switch0phy7>; > }; > > - port@8 { > + ethernet-port@8 { > reg = <0x8>; > label = "lan8"; > phy-handle = <&switch0phy8>; > }; > > - port@9 { > + ethernet-port@9 { > reg = <0x9>; > label = "cpu"; > ethernet = <ð1>; > @@ -410,7 +415,7 @@ port@9 { > managed = "in-band-status"; > }; > > - switch0port10: port@a { > + switch0port10: ethernet-port@a { > reg = <0xa>; > label = "dsa"; > phy-mode = "2500base-x"; > @@ -430,7 +435,7 @@ port-sfp@a { > }; > }; > > - switch0@2 { > + ethernet-switch@2 { It's funny that you add a comment TO NOT rename switch nodes, then you proceed to do just that. Having that said, we need to suppress these warnings for the Marvell schema only: arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dtb: switch0@10: $nodename:0: 'switch0@10' does not match '^(ethernet-)?switch(@.*)?$' from schema $id: http://devicetree.org/schemas/net/dsa/marvell,mv88e6xxx.yaml# arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dtb: ethernet-switch@12: ethernet-ports: 'port-sfp@a' does not match any of the regexes: '^(ethernet-)?port@[0-9]+$', 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/net/dsa/marvell,mv88e6xxx.yaml# because someone _will_ fix them and break the boot in the process. Rob, Krzysztof, Conor, do you have any suggestion on how to achieve that? > compatible = "marvell,mv88e6085"; > reg = <0x2>; > dsa,member = <0 0>; > diff --git a/arch/arm64/boot/dts/marvell/armada-7040-mochabin.dts b/arch/arm64/boot/dts/marvell/armada-7040-mochabin.dts > index 48202810bf78..40b7ee7ead72 100644 > --- a/arch/arm64/boot/dts/marvell/armada-7040-mochabin.dts > +++ b/arch/arm64/boot/dts/marvell/armada-7040-mochabin.dts > @@ -301,10 +301,8 @@ eth2phy: ethernet-phy@1 { > }; > > /* 88E6141 Topaz switch */ > - switch: switch@3 { > + switch: ethernet-switch@3 { > compatible = "marvell,mv88e6085"; > - #address-cells = <1>; > - #size-cells = <0>; > reg = <3>; > > pinctrl-names = "default"; > @@ -314,35 +312,35 @@ switch: switch@3 { > interrupt-parent = <&cp0_gpio1>; > interrupts = <1 IRQ_TYPE_LEVEL_LOW>; > > - ports { > + ethernet-ports { > #address-cells = <1>; > #size-cells = <0>; > > - swport1: port@1 { > + swport1: ethernet-port@1 { > reg = <1>; > label = "lan0"; > phy-handle = <&swphy1>; > }; > > - swport2: port@2 { > + swport2: ethernet-port@2 { > reg = <2>; > label = "lan1"; > phy-handle = <&swphy2>; > }; > > - swport3: port@3 { > + swport3: ethernet-port@3 { > reg = <3>; > label = "lan2"; > phy-handle = <&swphy3>; > }; > > - swport4: port@4 { > + swport4: ethernet-port@4 { > reg = <4>; > label = "lan3"; > phy-handle = <&swphy4>; > }; > > - port@5 { > + ethernet-port@5 { > reg = <5>; > label = "cpu"; > ethernet = <&cp0_eth1>; > @@ -355,19 +353,19 @@ mdio { > #address-cells = <1>; > #size-cells = <0>; > > - swphy1: swphy1@17 { > + swphy1: ethernet-phy@17 { > reg = <17>; > }; > > - swphy2: swphy2@18 { > + swphy2: ethernet-phy@18 { > reg = <18>; > }; > > - swphy3: swphy3@19 { > + swphy3: ethernet-phy@19 { > reg = <19>; > }; > > - swphy4: swphy4@20 { > + swphy4: ethernet-phy@20 { > reg = <20>; > }; > }; Robert, would you mind ACKing the MOCHAbin change? > diff --git a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts > index 4125202028c8..67892f0d2863 100644 > --- a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts > +++ b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts > @@ -497,42 +497,42 @@ ge_phy: ethernet-phy@0 { > reset-deassert-us = <10000>; > }; > > - switch0: switch0@4 { > + switch0: ethernet-switch@4 { > compatible = "marvell,mv88e6085"; > reg = <4>; > pinctrl-names = "default"; > pinctrl-0 = <&cp1_switch_reset_pins>; > reset-gpios = <&cp1_gpio1 24 GPIO_ACTIVE_LOW>; > > - ports { > + ethernet-ports { > #address-cells = <1>; > #size-cells = <0>; > > - port@1 { > + ethernet-port@1 { > reg = <1>; > label = "lan2"; > phy-handle = <&switch0phy0>; > }; > > - port@2 { > + ethernet-port@2 { > reg = <2>; > label = "lan1"; > phy-handle = <&switch0phy1>; > }; > > - port@3 { > + ethernet-port@3 { > reg = <3>; > label = "lan4"; > phy-handle = <&switch0phy2>; > }; > > - port@4 { > + ethernet-port@4 { > reg = <4>; > label = "lan3"; > phy-handle = <&switch0phy3>; > }; > > - port@5 { > + ethernet-port@5 { > reg = <5>; > label = "cpu"; > ethernet = <&cp1_eth2>; > @@ -545,19 +545,19 @@ mdio { > #address-cells = <1>; > #size-cells = <0>; > > - switch0phy0: switch0phy0@11 { > + switch0phy0: ethernet-phy@11 { > reg = <0x11>; > }; > > - switch0phy1: switch0phy1@12 { > + switch0phy1: ethernet-phy@12 { > reg = <0x12>; > }; > > - switch0phy2: switch0phy2@13 { > + switch0phy2: ethernet-phy@13 { > reg = <0x13>; > }; > > - switch0phy3: switch0phy3@14 { > + switch0phy3: ethernet-phy@14 { > reg = <0x14>; > }; > }; Russell, could you please do the same for this device tree? > diff --git a/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi b/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi > index 32cfb3e2efc3..7538ed56053b 100644 > --- a/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi > +++ b/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi > @@ -207,11 +207,9 @@ phy0: ethernet-phy@0 { > reg = <0>; > }; > > - switch6: switch0@6 { > + switch6: ethernet-switch@6 { > /* Actual device is MV88E6393X */ > compatible = "marvell,mv88e6190"; > - #address-cells = <1>; > - #size-cells = <0>; > reg = <6>; > interrupt-parent = <&cp0_gpio1>; > interrupts = <28 IRQ_TYPE_LEVEL_LOW>; > @@ -220,59 +218,59 @@ switch6: switch0@6 { > > dsa,member = <0 0>; > > - ports { > + ethernet-ports { > #address-cells = <1>; > #size-cells = <0>; > > - port@1 { > + ethernet-port@1 { > reg = <1>; > label = "p1"; > phy-handle = <&switch0phy1>; > }; > > - port@2 { > + ethernet-port@2 { > reg = <2>; > label = "p2"; > phy-handle = <&switch0phy2>; > }; > > - port@3 { > + ethernet-port@3 { > reg = <3>; > label = "p3"; > phy-handle = <&switch0phy3>; > }; > > - port@4 { > + ethernet-port@4 { > reg = <4>; > label = "p4"; > phy-handle = <&switch0phy4>; > }; > > - port@5 { > + ethernet-port@5 { > reg = <5>; > label = "p5"; > phy-handle = <&switch0phy5>; > }; > > - port@6 { > + ethernet-port@6 { > reg = <6>; > label = "p6"; > phy-handle = <&switch0phy6>; > }; > > - port@7 { > + ethernet-port@7 { > reg = <7>; > label = "p7"; > phy-handle = <&switch0phy7>; > }; > > - port@8 { > + ethernet-port@8 { > reg = <8>; > label = "p8"; > phy-handle = <&switch0phy8>; > }; > > - port@9 { > + ethernet-port@9 { > reg = <9>; > label = "p9"; > phy-mode = "10gbase-r"; > @@ -280,7 +278,7 @@ port@9 { > managed = "in-band-status"; > }; > > - port@a { > + ethernet-port@a { > reg = <10>; > ethernet = <&cp0_eth0>; > phy-mode = "10gbase-r"; > @@ -293,35 +291,35 @@ mdio { > #address-cells = <1>; > #size-cells = <0>; > > - switch0phy1: switch0phy1@1 { > + switch0phy1: ethernet-phy@1 { > reg = <0x1>; > }; > > - switch0phy2: switch0phy2@2 { > + switch0phy2: ethernet-phy@2 { > reg = <0x2>; > }; > > - switch0phy3: switch0phy3@3 { > + switch0phy3: ethernet-phy@3 { > reg = <0x3>; > }; > > - switch0phy4: switch0phy4@4 { > + switch0phy4: ethernet-phy@4 { > reg = <0x4>; > }; > > - switch0phy5: switch0phy5@5 { > + switch0phy5: ethernet-phy@5 { > reg = <0x5>; > }; > > - switch0phy6: switch0phy6@6 { > + switch0phy6: ethernet-phy@6 { > reg = <0x6>; > }; > > - switch0phy7: switch0phy7@7 { > + switch0phy7: ethernet-phy@7 { > reg = <0x7>; > }; > > - switch0phy8: switch0phy8@8 { > + switch0phy8: ethernet-phy@8 { > reg = <0x8>; > }; > }; Chris, does this look okay?
On Tue, Oct 24, 2023 at 09:28:42PM +0300, Vladimir Oltean wrote: > U-Boot code does this, so you can't rename "ports": > > /* > * now if there are more switches or a SFP module coming after, > * enable corresponding ports > */ > if (id < peridot + topaz - 1) { > res = fdt_status_okay_by_pathf(blob, > "%s/switch%i@%x/ports/port@a", > mdio_path, id, addr); > } else if (id == peridot - 1 && !topaz && sfp) { > res = fdt_status_okay_by_pathf(blob, > "%s/switch%i@%x/ports/port-sfp@a", > mdio_path, id, addr); > } else { > res = 0; > } So that's now two platforms that do this. I think at this stage, we have to regard these node paths as an ABI that we just can't change without causing some breakage. If we can't fix up all platforms, doesn't that make the YAML conversion harder? You've asked me to test the Clearfog GT-8k change - which is something that won't happen for a while as I don't have the hardware to hand at my current location, nor remotely. What I can do is poke about in the u-boot sources I have for that board and see# whether it's doing anything with those node paths. Off the top of my# head, given what the board is, I think it's highly unlikely though,# but I will check - possibly tomorrow.
On Tue, Oct 24, 2023 at 08:03:47PM +0100, Russell King (Oracle) wrote: > On Tue, Oct 24, 2023 at 09:28:42PM +0300, Vladimir Oltean wrote: > > U-Boot code does this, so you can't rename "ports": > > > > /* > > * now if there are more switches or a SFP module coming after, > > * enable corresponding ports > > */ > > if (id < peridot + topaz - 1) { > > res = fdt_status_okay_by_pathf(blob, > > "%s/switch%i@%x/ports/port@a", > > mdio_path, id, addr); > > } else if (id == peridot - 1 && !topaz && sfp) { > > res = fdt_status_okay_by_pathf(blob, > > "%s/switch%i@%x/ports/port-sfp@a", > > mdio_path, id, addr); > > } else { > > res = 0; > > } > > So that's now two platforms that do this. I think at this stage, we > have to regard these node paths as an ABI that we just can't change > without causing some breakage. No, it's still the same as the one I pointed out on v4: https://patchwork.kernel.org/project/netdevbpf/patch/20231018-marvell-88e6152-wan-led-v4-5-3ee0c67383be@linaro.org/ aka the Turris MOX. But it looks like my previous comment wasn't quite clear, thus Linus' conversion still cleans up too much in this device tree. > If we can't fix up all platforms, doesn't that make the YAML > conversion harder? Well, I do see this as a valid concern that could potentially bite back, yes. I did express that the schema should not emit warnings for $nodename, but TBH I don't know how that constraint could be eliminated: https://patchwork.kernel.org/project/netdevbpf/patch/20231018-marvell-88e6152-wan-led-v4-6-3ee0c67383be@linaro.org/ > You've asked me to test the Clearfog GT-8k change - which is something > that won't happen for a while as I don't have the hardware to hand at > my current location, nor remotely. > > What I can do is poke about in the u-boot sources I have for that > board and see# whether it's doing anything with those node paths. Off > the top of my# head, given what the board is, I think it's highly > unlikely though,# but I will check - possibly tomorrow. Ok, if U-Boot is the only bootloader, I also looked through the upstream board source files and only noticed any fixups for MOX. I don't know what these boards ship with, and how far that is from mainline U-Boot.
Hi All, On 25/10/23 07:28, Vladimir Oltean wrote: > Linus, > > On Tue, Oct 24, 2023 at 03:20:31PM +0200, Linus Walleij wrote: >> Fix some errors in the Marvell MV88E6xxx switch descriptions: >> - The top node had no address size or cells. >> - switch0@0 is not OK, should be ethernet-switch@0. >> - ports should be ethernet-ports >> - port@0 should be ethernet-port@0 >> - PHYs should be named ethernet-phy@ >> >> Reviewed-by: Andrew Lunn <andrew@lunn.ch> >> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> <snip> >> --- >> diff --git a/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi b/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi >> index 32cfb3e2efc3..7538ed56053b 100644 >> --- a/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi >> +++ b/arch/arm64/boot/dts/marvell/cn9130-crb.dtsi >> @@ -207,11 +207,9 @@ phy0: ethernet-phy@0 { >> reg = <0>; >> }; >> >> - switch6: switch0@6 { >> + switch6: ethernet-switch@6 { >> /* Actual device is MV88E6393X */ >> compatible = "marvell,mv88e6190"; >> - #address-cells = <1>; >> - #size-cells = <0>; >> reg = <6>; >> interrupt-parent = <&cp0_gpio1>; >> interrupts = <28 IRQ_TYPE_LEVEL_LOW>; >> @@ -220,59 +218,59 @@ switch6: switch0@6 { >> >> dsa,member = <0 0>; >> >> - ports { >> + ethernet-ports { >> #address-cells = <1>; >> #size-cells = <0>; >> >> - port@1 { >> + ethernet-port@1 { >> reg = <1>; >> label = "p1"; >> phy-handle = <&switch0phy1>; >> }; >> >> - port@2 { >> + ethernet-port@2 { >> reg = <2>; >> label = "p2"; >> phy-handle = <&switch0phy2>; >> }; >> >> - port@3 { >> + ethernet-port@3 { >> reg = <3>; >> label = "p3"; >> phy-handle = <&switch0phy3>; >> }; >> >> - port@4 { >> + ethernet-port@4 { >> reg = <4>; >> label = "p4"; >> phy-handle = <&switch0phy4>; >> }; >> >> - port@5 { >> + ethernet-port@5 { >> reg = <5>; >> label = "p5"; >> phy-handle = <&switch0phy5>; >> }; >> >> - port@6 { >> + ethernet-port@6 { >> reg = <6>; >> label = "p6"; >> phy-handle = <&switch0phy6>; >> }; >> >> - port@7 { >> + ethernet-port@7 { >> reg = <7>; >> label = "p7"; >> phy-handle = <&switch0phy7>; >> }; >> >> - port@8 { >> + ethernet-port@8 { >> reg = <8>; >> label = "p8"; >> phy-handle = <&switch0phy8>; >> }; >> >> - port@9 { >> + ethernet-port@9 { >> reg = <9>; >> label = "p9"; >> phy-mode = "10gbase-r"; >> @@ -280,7 +278,7 @@ port@9 { >> managed = "in-band-status"; >> }; >> >> - port@a { >> + ethernet-port@a { >> reg = <10>; >> ethernet = <&cp0_eth0>; >> phy-mode = "10gbase-r"; >> @@ -293,35 +291,35 @@ mdio { >> #address-cells = <1>; >> #size-cells = <0>; >> >> - switch0phy1: switch0phy1@1 { >> + switch0phy1: ethernet-phy@1 { >> reg = <0x1>; >> }; >> >> - switch0phy2: switch0phy2@2 { >> + switch0phy2: ethernet-phy@2 { >> reg = <0x2>; >> }; >> >> - switch0phy3: switch0phy3@3 { >> + switch0phy3: ethernet-phy@3 { >> reg = <0x3>; >> }; >> >> - switch0phy4: switch0phy4@4 { >> + switch0phy4: ethernet-phy@4 { >> reg = <0x4>; >> }; >> >> - switch0phy5: switch0phy5@5 { >> + switch0phy5: ethernet-phy@5 { >> reg = <0x5>; >> }; >> >> - switch0phy6: switch0phy6@6 { >> + switch0phy6: ethernet-phy@6 { >> reg = <0x6>; >> }; >> >> - switch0phy7: switch0phy7@7 { >> + switch0phy7: ethernet-phy@7 { >> reg = <0x7>; >> }; >> >> - switch0phy8: switch0phy8@8 { >> + switch0phy8: ethernet-phy@8 { >> reg = <0x8>; >> }; >> }; > Chris, does this look okay? There's nothing in the u-boot code for the CN9130-CRB that cares about the switch so I don't think there's any issue ABI wise. We are working on our own CN9130 based router with a L2 switch but it's at a point we can follow whatever upstream decide is the final schema. In terms of my personal preference the schema quoted up thread has the pattern '^(ethernet-)?switch(@.*)?$' (i.e. the 'ethernet-' part is optional) so I'd personally prefer switch0@6 -> switch@6 but that's only a slight preference because I deal with Ethernet switches day in day out.
Hello Chris, On Tue, Oct 24, 2023 at 08:10:14PM +0000, Chris Packham wrote: > > Chris, does this look okay? > > There's nothing in the u-boot code for the CN9130-CRB that cares about > the switch so I don't think there's any issue ABI wise. We are working > on our own CN9130 based router with a L2 switch but it's at a point we > can follow whatever upstream decide is the final schema. Thank you for taking the time to confirm. > In terms of my personal preference the schema quoted up thread has the > pattern '^(ethernet-)?switch(@.*)?$' (i.e. the 'ethernet-' part is > optional) so I'd personally prefer switch0@6 -> switch@6 but that's only > a slight preference because I deal with Ethernet switches day in day out. The movement originally came from "ports" to "ethernet-ports" at Rob's suggestion, because of the name clash with the ports from graph.yaml. Then we also did "switch" -> "ethernet-switch" because you'll also find "pcie-switch" in mainline device trees.
Hello: This series was applied to netdev/net-next.git (main) by David S. Miller <davem@davemloft.net>: On Tue, 24 Oct 2023 15:20:26 +0200 you wrote: > The Marvell switches are lacking DT bindings. > > I need proper schema checking to add LED support to the > Marvell switch. Just how it is, it can't go on like this. > > Some Device Tree fixes are included in the series, these > remove the major and most annoying warnings fallout noise: > some warnings remain, and these are of more serious nature, > such as missing phy-mode. They can be applied individually, > or to the networking tree with the rest of the patches. > > [...] Here is the summary with links: - [net-next,v7,1/7] dt-bindings: net: dsa: Require ports or ethernet-ports https://git.kernel.org/netdev/net-next/c/b5ef61718ad7 - [net-next,v7,2/7] dt-bindings: net: mvusb: Fix up DSA example https://git.kernel.org/netdev/net-next/c/ddae07ce9bb3 - [net-next,v7,3/7] ARM: dts: marvell: Fix some common switch mistakes https://git.kernel.org/netdev/net-next/c/2b83557a588f - [net-next,v7,4/7] ARM: dts: nxp: Fix some common switch mistakes https://git.kernel.org/netdev/net-next/c/bfedd8423643 - [net-next,v7,5/7] ARM64: dts: marvell: Fix some common switch mistakes https://git.kernel.org/netdev/net-next/c/605a5f5d406d - [net-next,v7,6/7] dt-bindings: marvell: Rewrite MV88E6xxx in schema https://git.kernel.org/netdev/net-next/c/0f35369b4efe - [net-next,v7,7/7] dt-bindings: marvell: Add Marvell MV88E6060 DSA schema https://git.kernel.org/netdev/net-next/c/53313ed25ba8 You are awesome, thank you!
Hi Dave, On Wed, Oct 25, 2023 at 09:30:27AM +0000, patchwork-bot+netdevbpf@kernel.org wrote: > Hello: > > This series was applied to netdev/net-next.git (main) > by David S. Miller <davem@davemloft.net>: > > On Tue, 24 Oct 2023 15:20:26 +0200 you wrote: > > The Marvell switches are lacking DT bindings. > > > > I need proper schema checking to add LED support to the > > Marvell switch. Just how it is, it can't go on like this. > > > > Some Device Tree fixes are included in the series, these > > remove the major and most annoying warnings fallout noise: > > some warnings remain, and these are of more serious nature, > > such as missing phy-mode. They can be applied individually, > > or to the networking tree with the rest of the patches. > > > > [...] Can you please revert this series? It breaks the boot on the Turris MOX board.
On Wed, 25 Oct 2023 12:36:32 +0300 Vladimir Oltean wrote: > Can you please revert this series? It breaks the boot on the Turris MOX > board. Done!
Hi Vladimir, thanks for paging in the right maintainers to look at the respective boards, much appreciated! On Tue, Oct 24, 2023 at 8:28 PM Vladimir Oltean <olteanv@gmail.com> wrote: > I looked at U-Boot's ft_board_setup() from board/Marvell/mvebu_armada-37xx/board.c > and it doesn't appear to do anything with the switch. But after the MOX precedent > (which is _still_ problematic, more below), I still think we are way too > trigger-happy with this, and it would be good to ask someone who has the > Espressobin to test. Yeah that would be great. > > - /* switch nodes are enabled by U-Boot if modules are present */ > > + /* > > + * NOTE: switch nodes are enabled by U-Boot if modules are present > > + * DO NOT change this node name (switch0@10) even if it is not following > > + * conventions! Deployed U-Boot binaries are explicitly looking for > > + * this node in order to augment the device tree! > > + */ > > Not "this node", but all switch nodes! (...) > It's funny that you add a comment TO NOT rename switch nodes, then you > proceed to do just that. Yeah it's a stupid mistake on my behalf. :( too sleepy or something. I fixed it up, and put a small comment above each of them not to change the node name. > > - ports { > > + ethernet-ports { > > U-Boot code does this, so you can't rename "ports": > > /* > * now if there are more switches or a SFP module coming after, > * enable corresponding ports > */ > if (id < peridot + topaz - 1) { > res = fdt_status_okay_by_pathf(blob, > "%s/switch%i@%x/ports/port@a", > mdio_path, id, addr); > } else if (id == peridot - 1 && !topaz && sfp) { > res = fdt_status_okay_by_pathf(blob, > "%s/switch%i@%x/ports/port-sfp@a", > mdio_path, id, addr); > } else { > res = 0; > } > > > #address-cells = <1>; > > #size-cells = <0>; > > > > - port@1 { > > + ethernet-port@1 { > > or "port@.*", or "port-sfp@a", for the same reason. Here and everywhere > in this device tree. Basically only the ethernet-phy rename seems safe. Fair, reverted it all. > Having that said, we need to suppress these warnings for the Marvell > schema only: > > arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dtb: switch0@10: $nodename:0: 'switch0@10' does not match '^(ethernet-)?switch(@.*)?$' > from schema $id: http://devicetree.org/schemas/net/dsa/marvell,mv88e6xxx.yaml# > arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dtb: ethernet-switch@12: ethernet-ports: 'port-sfp@a' does not match any of the regexes: '^(ethernet-)?port@[0-9]+$', 'pinctrl-[0-9]+' > from schema $id: http://devicetree.org/schemas/net/dsa/marvell,mv88e6xxx.yaml# > > because someone _will_ fix them and break the boot in the process. Really? I think you will stop them from doing that every single time ;) Jokes aside, we certainly need a way to suppress this warning. > Rob, Krzysztof, Conor, do you have any suggestion on how to achieve that? What we can do easily is to override the $nodename requirement for a certain compatible with one of those - if: constructions, but that would unfortunately make us be lax on every other board as well. What we want to achieve is: 1. Match on the top level compatible (under '/') with contains: const: cznic,turris-mox 2. Then relax requirements on the switch nodes if that is true. I assume I would have to go into Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml and put hard requirement on node names from there. I'm not sure this would work or that it's even possible, or desireable. But... We *COULD* add a second over-specified compatible to the switch node. Such as: switch0@10 { compatible = "marvell,turris-mox-mv88e6190-switch", "marvell,mv88e6190"; (and the same for the 6085 version) And use that to relax the requirement for that variant with an - if: statemement. This should work fine since U-Boot is only looking for nodenames, not compatible strings. I think I will try this approach. Yours, Linus Walleij
On Tue, Oct 24, 2023 at 9:03 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > If we can't fix up all platforms, doesn't that make the YAML > conversion harder? It does. I'm scouting some possible routes. I'm leaning toward introducing extra compatibles to use as markers for special node name rules. > You've asked me to test the Clearfog GT-8k change - which is something > that won't happen for a while as I don't have the hardware to hand at > my current location, nor remotely. No hurry. These bindings have been sitting unconverted for some time and all driving it now is my need for formalization and that can wait. > What I can do is poke about in the u-boot sources I have for that > board and see# whether it's doing anything with those node paths. Off > the top of my# head, given what the board is, I think it's highly > unlikely though,# but I will check - possibly tomorrow. Thanks Russell, much appreciated! Yours, Linus Walleij
On Wed, Oct 25, 2023 at 9:48 PM Linus Walleij <linus.walleij@linaro.org> wrote: > We *COULD* add a second over-specified compatible to the switch > node. Such as: > > switch0@10 { > compatible = "marvell,turris-mox-mv88e6190-switch", > "marvell,mv88e6190"; > > (and the same for the 6085 version) > > And use that to relax the requirement for that variant with an - if: > statemement. > > This should work fine since U-Boot is only looking for nodenames, not > compatible strings. I think I will try this approach. This works. Compatibles added like such to the turris-mox nodes: switch0@10 { - compatible = "marvell,mv88e6190"; + compatible = "marvell,turris-mox-mv88e6190", "marvell,mv88e6190"; The mv88e6xxx schema will look like so: properties: compatible: + oneOf: + - enum: + - marvell,mv88e6085 + - marvell,mv88e6190 + - marvell,mv88e6250 (...) + - items: + - const: marvell,turris-mox-mv88e6085 + - const: marvell,mv88e6085 + - items: + - const: marvell,turris-mox-mv88e6190 + - const: marvell,mv88e6190 Then ethernet-switch.yaml gets this: -properties: - $nodename: - pattern: "^(ethernet-)?switch(@.*)?$" +allOf: + # This condition is here to satisfy the case where certain device + # nodes have to preserve non-standard names because of + # backward-compatibility with boot loaders inspecting certain + # node names. + - if: + properties: + compatible: + contains: + enum: + - marvell,turris-mox-mv88e6085 + - marvell,turris-mox-mv88e6190 + then: + properties: + $nodename: + pattern: "switch[0-3]@[0-3]+$" + else: + properties: + $nodename: + pattern: "^(ethernet-)?switch(@.*)?$" This latter thing is maybe not so nice for everyone to process. The alternative is however to copy all of dsa.yaml, dsa-port.yaml and ethernet-port.yaml (maybe more) into the Marvell binding. Which I can do, of course. (qca8k is already deviant). Unless there is a better way. Yours, Linus Walleij
> The mv88e6xxx schema will look like so: > > properties: > compatible: > + oneOf: > + - enum: > + - marvell,mv88e6085 > + - marvell,mv88e6190 > + - marvell,mv88e6250 > (...) > + - items: > + - const: marvell,turris-mox-mv88e6085 > + - const: marvell,mv88e6085 > + - items: > + - const: marvell,turris-mox-mv88e6190 > + - const: marvell,mv88e6190 Lets see what the DT Maintainers think of this. But if we do go this way, i would like to see a comment here with an explanation. What we don't want is developers thinking they should add new compatibles for whatever board they are adding. Andrew
The Marvell switches are lacking DT bindings. I need proper schema checking to add LED support to the Marvell switch. Just how it is, it can't go on like this. Some Device Tree fixes are included in the series, these remove the major and most annoying warnings fallout noise: some warnings remain, and these are of more serious nature, such as missing phy-mode. They can be applied individually, or to the networking tree with the rest of the patches. Thanks to Andrew Lunn, Vladimir Oltean and Russell King for excellent review and feedback! Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- Changes in v7: - Fix the elaborate spacing to satisfy yamllint in the ports/ethernet-ports requirement. - Link to v6: https://lore.kernel.org/r/20231024-marvell-88e6152-wan-led-v6-0-993ab0949344@linaro.org Changes in v6: - Fix ports/ethernet-ports requirement with proper indenting (hopefully). - Link to v5: https://lore.kernel.org/r/20231023-marvell-88e6152-wan-led-v5-0-0e82952015a7@linaro.org Changes in v5: - Consistently rename switch@n to ethernet-switch@n in all cleanup patches - Consistently rename ports to ethernet-ports in all cleanup patches - Consistently rename all port@n to ethernet-port@n in all cleanup patches - Consistently rename all phy@n to ethernet-phy@n in all cleanup patches - Restore the nodename on the Turris MOX which has a U-Boot binary using the nodename as ABI, put in a blurb warning about this so no-one else tries to change it in the future. - Drop dsa.yaml direct references where we reference dsa.yaml#/$defs/ethernet-ports - Replace the conjured MV88E6xxx example by a better one based on imx6qdl plus strictly named nodes and added reset-gpios for a more complete example, and another example using the interrupt controller based on armada-381-netgear-gs110emx.dts - Bump lineage to 2008 as Vladimir says the code was developed starting 2008. - Link to v4: https://lore.kernel.org/r/20231018-marvell-88e6152-wan-led-v4-0-3ee0c67383be@linaro.org Changes in v4: - Rebase the series on top of Rob's series "dt-bindings: net: Child node schema cleanups" (or the hex numbered ports will not work) - Fix up a whitespacing error corrupting v3... - Add a new patch making the generic DSA binding require ports or ethernet-ports in the switch node. - Drop any corrections of port@a in the patches. - Drop oneOf in the compatible enum for mv88e6xxx - Use ethernet-switch, ethernet-ports and ethernet-phy in the examples - Transclude the dsa.yaml#/$defs/ethernet-ports define for ports - Move the DTS and binding fixes first, before the actual bindings, so they apply without (too many) warnings as fallout. - Drop stray colon in text. - Drop example port in the mveusb binding. - Link to v3: https://lore.kernel.org/r/20231016-marvell-88e6152-wan-led-v3-0-38cd449dfb15@linaro.org Changes in v3: - Fix up a related mvusb example in a different binding that the scripts were complaining about. - Fix up the wording on internal vs external MDIO buses in the mv88e6xxx binding document. - Remove pointless label and put the right rev-mii into the MV88E6060 schema. - Link to v2: https://lore.kernel.org/r/20231014-marvell-88e6152-wan-led-v2-0-7fca08b68849@linaro.org Changes in v2: - Break out a separate Marvell MV88E6060 binding file. I stand corrected. - Drop the idea to rely on nodename mdio-external for the external MDIO bus, keep the compatible, drop patch for the driver. - Fix more Marvell DT mistakes. - Fix NXP DT mistakes in a separate patch. - Fix Marvell ARM64 mistakes in a separate patch. - Link to v1: https://lore.kernel.org/r/20231013-marvell-88e6152-wan-led-v1-0-0712ba99857c@linaro.org --- Linus Walleij (7): dt-bindings: net: dsa: Require ports or ethernet-ports dt-bindings: net: mvusb: Fix up DSA example ARM: dts: marvell: Fix some common switch mistakes ARM: dts: nxp: Fix some common switch mistakes ARM64: dts: marvell: Fix some common switch mistakes dt-bindings: marvell: Rewrite MV88E6xxx in schema dt-bindings: marvell: Add Marvell MV88E6060 DSA schema Documentation/devicetree/bindings/net/dsa/dsa.yaml | 6 + .../bindings/net/dsa/marvell,mv88e6060.yaml | 88 ++++++ .../bindings/net/dsa/marvell,mv88e6xxx.yaml | 330 +++++++++++++++++++++ .../devicetree/bindings/net/dsa/marvell.txt | 109 ------- .../devicetree/bindings/net/marvell,mvusb.yaml | 7 +- MAINTAINERS | 3 +- arch/arm/boot/dts/marvell/armada-370-rd.dts | 24 +- .../dts/marvell/armada-381-netgear-gs110emx.dts | 44 ++- .../dts/marvell/armada-385-clearfog-gtr-l8.dts | 38 +-- .../dts/marvell/armada-385-clearfog-gtr-s4.dts | 22 +- arch/arm/boot/dts/marvell/armada-385-linksys.dtsi | 18 +- .../boot/dts/marvell/armada-385-turris-omnia.dts | 20 +- arch/arm/boot/dts/marvell/armada-388-clearfog.dts | 20 +- .../boot/dts/marvell/armada-xp-linksys-mamba.dts | 18 +- arch/arm/boot/dts/nxp/vf/vf610-zii-cfu1.dts | 14 +- arch/arm/boot/dts/nxp/vf/vf610-zii-scu4-aib.dts | 70 ++--- arch/arm/boot/dts/nxp/vf/vf610-zii-spb4.dts | 18 +- arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts | 20 +- arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-spu3.dts | 18 +- .../dts/marvell/armada-3720-espressobin-ultra.dts | 14 +- .../boot/dts/marvell/armada-3720-espressobin.dtsi | 20 +- .../boot/dts/marvell/armada-3720-gl-mv1000.dts | 20 +- .../boot/dts/marvell/armada-3720-turris-mox.dts | 189 ++++++------ .../boot/dts/marvell/armada-7040-mochabin.dts | 24 +- .../dts/marvell/armada-8040-clearfog-gt-8k.dts | 22 +- arch/arm64/boot/dts/marvell/cn9130-crb.dtsi | 42 ++- 26 files changed, 761 insertions(+), 457 deletions(-) --- base-commit: 1c9be5fea84e409542a186893d219bf7cff22f5a change-id: 20231008-marvell-88e6152-wan-led-88c43b7fd2fd Best regards,