| Message ID | 20200929113209.3767787-3-vladimir.oltean@nxp.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add Seville Ethernet switch to T1040RDB | expand |
Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru> 29.09.2020 14:32, Vladimir Oltean пишет: > From: Vladimir Oltean <olteanv@gmail.com> > > Define the network interface names for the switch ports and hook them up > to the 2 QSGMII PHYs that are onboard. > > A conscious decision was taken to go along with the numbers that are > written on the front panel of the board and not with the hardware > numbers of the switch chip ports. The 2 numbering schemes are > shifted by 8. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> > --- > Changes in v2: > Use the existing way of accessing the mdio bus and not labels. > > arch/powerpc/boot/dts/fsl/t1040rdb.dts | 115 +++++++++++++++++++++++++ > 1 file changed, 115 insertions(+) > > diff --git a/arch/powerpc/boot/dts/fsl/t1040rdb.dts b/arch/powerpc/boot/dts/fsl/t1040rdb.dts > index 65ff34c49025..3fd08a2b6dcb 100644 > --- a/arch/powerpc/boot/dts/fsl/t1040rdb.dts > +++ b/arch/powerpc/boot/dts/fsl/t1040rdb.dts > @@ -64,6 +64,40 @@ mdio@fc000 { > phy_sgmii_2: ethernet-phy@3 { > reg = <0x03>; > }; > + > + /* VSC8514 QSGMII PHY */ > + phy_qsgmii_0: ethernet-phy@4 { > + reg = <0x4>; > + }; > + > + phy_qsgmii_1: ethernet-phy@5 { > + reg = <0x5>; > + }; > + > + phy_qsgmii_2: ethernet-phy@6 { > + reg = <0x6>; > + }; > + > + phy_qsgmii_3: ethernet-phy@7 { > + reg = <0x7>; > + }; > + > + /* VSC8514 QSGMII PHY */ > + phy_qsgmii_4: ethernet-phy@8 { > + reg = <0x8>; > + }; > + > + phy_qsgmii_5: ethernet-phy@9 { > + reg = <0x9>; > + }; > + > + phy_qsgmii_6: ethernet-phy@a { > + reg = <0xa>; > + }; > + > + phy_qsgmii_7: ethernet-phy@b { > + reg = <0xb>; > + }; > }; > }; > }; > @@ -76,3 +110,84 @@ cpld@3,0 { > }; > > #include "t1040si-post.dtsi" > + > +&seville_switch { > + status = "okay"; > +}; > + > +&seville_port0 { > + managed = "in-band-status"; > + phy-handle = <&phy_qsgmii_0>; > + phy-mode = "qsgmii"; > + /* ETH4 written on chassis */ > + label = "swp4"; > + status = "okay"; > +}; > + > +&seville_port1 { > + managed = "in-band-status"; > + phy-handle = <&phy_qsgmii_1>; > + phy-mode = "qsgmii"; > + /* ETH5 written on chassis */ > + label = "swp5"; > + status = "okay"; > +}; > + > +&seville_port2 { > + managed = "in-band-status"; > + phy-handle = <&phy_qsgmii_2>; > + phy-mode = "qsgmii"; > + /* ETH6 written on chassis */ > + label = "swp6"; > + status = "okay"; > +}; > + > +&seville_port3 { > + managed = "in-band-status"; > + phy-handle = <&phy_qsgmii_3>; > + phy-mode = "qsgmii"; > + /* ETH7 written on chassis */ > + label = "swp7"; > + status = "okay"; > +}; > + > +&seville_port4 { > + managed = "in-band-status"; > + phy-handle = <&phy_qsgmii_4>; > + phy-mode = "qsgmii"; > + /* ETH8 written on chassis */ > + label = "swp8"; > + status = "okay"; > +}; > + > +&seville_port5 { > + managed = "in-band-status"; > + phy-handle = <&phy_qsgmii_5>; > + phy-mode = "qsgmii"; > + /* ETH9 written on chassis */ > + label = "swp9"; > + status = "okay"; > +}; > + > +&seville_port6 { > + managed = "in-band-status"; > + phy-handle = <&phy_qsgmii_6>; > + phy-mode = "qsgmii"; > + /* ETH10 written on chassis */ > + label = "swp10"; > + status = "okay"; > +}; > + > +&seville_port7 { > + managed = "in-band-status"; > + phy-handle = <&phy_qsgmii_7>; > + phy-mode = "qsgmii"; > + /* ETH11 written on chassis */ > + label = "swp11"; > + status = "okay"; > +}; > + > +&seville_port8 { > + ethernet = <&enet0>; > + status = "okay"; > +}; >
> +&seville_port0 { > + managed = "in-band-status"; > + phy-handle = <&phy_qsgmii_0>; > + phy-mode = "qsgmii"; > + /* ETH4 written on chassis */ > + label = "swp4"; If ETH4 is on the chassis why not use ETH4? Andrew
On Tue, Sep 29, 2020 at 09:11:53PM +0200, Andrew Lunn wrote: > > +&seville_port0 { > > + managed = "in-band-status"; > > + phy-handle = <&phy_qsgmii_0>; > > + phy-mode = "qsgmii"; > > + /* ETH4 written on chassis */ > > + label = "swp4"; > > If ETH4 is on the chassis why not use ETH4? You mean all-caps, just like that? I don't know, I never saw an interface named in all-caps, it looks strange to me. I understand that board designers are typically case-insensitive, and that's kind of what my problem is, "eth4" is clashing with the default naming scheme of the kernel and I also want to avoid that. All in all, this is a reference design board, I don't care too much. I've seen the "swp" convention being quite frequent, and I thought that would be more intuitive. I've been using the same scheme (the switch ports starting from swp2, corresponding to ETH2 on the chassis) for the LS1021A-TSN board (arch/arm/boot/dts/ls1021a-tsn.dts) and my users haven't complained about it. Plus, it's not like the dpaa-eth (standalone) ports are named after the chassis labels. Freescale/NXP typically ships an udev rule file that names the interface after the associated FMan hardware port (for example, the DSA master for the switch on this SoC is called "fm1-gb0", and it's an internal port having nothing to do with ETH0, which is "fm1-gb3"). I think it's a bit strange that the Rest Of World doesn't allow interface naming via device tree, on this board the switch ports are not where the big interface naming problem is. Although I'm not even sure what to do to not increase it even more. With users being used to have ETH0 going to fm1-gb3, maybe naming ETH4 as swp4 isn't the brightest idea, true...
On Tue, Sep 29, 2020 at 07:39:54PM +0000, Vladimir Oltean wrote: > On Tue, Sep 29, 2020 at 09:11:53PM +0200, Andrew Lunn wrote: > > > +&seville_port0 { > > > + managed = "in-band-status"; > > > + phy-handle = <&phy_qsgmii_0>; > > > + phy-mode = "qsgmii"; > > > + /* ETH4 written on chassis */ > > > + label = "swp4"; > > > > If ETH4 is on the chassis why not use ETH4? > > You mean all-caps, just like that? Yes. DSA is often used in WiFI access point, etc. The user is not a computer professional. If the WebGUI says ETH4, and the label on the front says ETH4, they probably think the two are the same, and are happy. I have one box which does not have an labels on the front panels, but the industrial sockets for Ethernet are colour coded. So the interface names are red, blue, green, to match the socket colour, and the cable set is also colour coded the same. So long as it is unique, the kernel does not care. So make it easy for the user. Andrew
On Tue, Sep 29, 2020 at 10:10:48PM +0200, Andrew Lunn wrote: > On Tue, Sep 29, 2020 at 07:39:54PM +0000, Vladimir Oltean wrote: > > On Tue, Sep 29, 2020 at 09:11:53PM +0200, Andrew Lunn wrote: > > > > +&seville_port0 { > > > > + managed = "in-band-status"; > > > > + phy-handle = <&phy_qsgmii_0>; > > > > + phy-mode = "qsgmii"; > > > > + /* ETH4 written on chassis */ > > > > + label = "swp4"; > > > > > > If ETH4 is on the chassis why not use ETH4? > > > > You mean all-caps, just like that? > > Yes. > > DSA is often used in WiFI access point, etc. The user is not a > computer professional. If the WebGUI says ETH4, and the label on the > front says ETH4, they probably think the two are the same, and are > happy. > > I have one box which does not have an labels on the front panels, but > the industrial sockets for Ethernet are colour coded. So the interface > names are red, blue, green, to match the socket colour, and the cable > set is also colour coded the same. > > So long as it is unique, the kernel does not care. So make it easy for > the user. It would look like this: [root@T1040 ~] # ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/ether de:91:41:1a:92:b8 brd ff:ff:ff:ff:ff:ff 3: fm1-gb3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:68 brd ff:ff:ff:ff:ff:ff 4: fm1-gb4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:88 brd ff:ff:ff:ff:ff:ff 5: fm1-gb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:08 brd ff:ff:ff:ff:ff:ff 6: fm1-gb1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:28 brd ff:ff:ff:ff:ff:ff 7: fm1-gb2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:48 brd ff:ff:ff:ff:ff:ff 8: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 9: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 10: ETH4@fm1-gb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:08 brd ff:ff:ff:ff:ff:ff 11: ETH5@fm1-gb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:08 brd ff:ff:ff:ff:ff:ff 12: ETH6@fm1-gb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:08 brd ff:ff:ff:ff:ff:ff 13: ETH7@fm1-gb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:08 brd ff:ff:ff:ff:ff:ff 14: ETH8@fm1-gb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:08 brd ff:ff:ff:ff:ff:ff 15: ETH9@fm1-gb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:08 brd ff:ff:ff:ff:ff:ff 16: ETH10@fm1-gb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:08 brd ff:ff:ff:ff:ff:ff 17: ETH11@fm1-gb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000 link/ether 00:1f:7b:6a:02:08 brd ff:ff:ff:ff:ff:ff [root@T1040 ~] # ip link set ETH4 down [ 94.942190] mscc_seville ffe800000.ethernet-switch ETH4: Link is Down [root@T1040 ~] # ip link set ETH4 up [ 100.262533] mscc_seville ffe800000.ethernet-switch ETH4: configuring for inband/qsgmii link mode [ 100.272122] 8021q: adding VLAN 0 to HW filter on device ETH4 [ 103.333369] mscc_seville ffe800000.ethernet-switch ETH4: Link is Up - 1Gbps/Full - flow control rx/tx [ 103.342697] IPv6: ADDRCONF(NETDEV_CHANGE): ETH4: link becomes ready I'm not in love, but I guess at least there won't be any doubt if they are named like this. I'm sending another revision with these names soon. Thanks, -Vladimir
diff --git a/arch/powerpc/boot/dts/fsl/t1040rdb.dts b/arch/powerpc/boot/dts/fsl/t1040rdb.dts index 65ff34c49025..3fd08a2b6dcb 100644 --- a/arch/powerpc/boot/dts/fsl/t1040rdb.dts +++ b/arch/powerpc/boot/dts/fsl/t1040rdb.dts @@ -64,6 +64,40 @@ mdio@fc000 { phy_sgmii_2: ethernet-phy@3 { reg = <0x03>; }; + + /* VSC8514 QSGMII PHY */ + phy_qsgmii_0: ethernet-phy@4 { + reg = <0x4>; + }; + + phy_qsgmii_1: ethernet-phy@5 { + reg = <0x5>; + }; + + phy_qsgmii_2: ethernet-phy@6 { + reg = <0x6>; + }; + + phy_qsgmii_3: ethernet-phy@7 { + reg = <0x7>; + }; + + /* VSC8514 QSGMII PHY */ + phy_qsgmii_4: ethernet-phy@8 { + reg = <0x8>; + }; + + phy_qsgmii_5: ethernet-phy@9 { + reg = <0x9>; + }; + + phy_qsgmii_6: ethernet-phy@a { + reg = <0xa>; + }; + + phy_qsgmii_7: ethernet-phy@b { + reg = <0xb>; + }; }; }; }; @@ -76,3 +110,84 @@ cpld@3,0 { }; #include "t1040si-post.dtsi" + +&seville_switch { + status = "okay"; +}; + +&seville_port0 { + managed = "in-band-status"; + phy-handle = <&phy_qsgmii_0>; + phy-mode = "qsgmii"; + /* ETH4 written on chassis */ + label = "swp4"; + status = "okay"; +}; + +&seville_port1 { + managed = "in-band-status"; + phy-handle = <&phy_qsgmii_1>; + phy-mode = "qsgmii"; + /* ETH5 written on chassis */ + label = "swp5"; + status = "okay"; +}; + +&seville_port2 { + managed = "in-band-status"; + phy-handle = <&phy_qsgmii_2>; + phy-mode = "qsgmii"; + /* ETH6 written on chassis */ + label = "swp6"; + status = "okay"; +}; + +&seville_port3 { + managed = "in-band-status"; + phy-handle = <&phy_qsgmii_3>; + phy-mode = "qsgmii"; + /* ETH7 written on chassis */ + label = "swp7"; + status = "okay"; +}; + +&seville_port4 { + managed = "in-band-status"; + phy-handle = <&phy_qsgmii_4>; + phy-mode = "qsgmii"; + /* ETH8 written on chassis */ + label = "swp8"; + status = "okay"; +}; + +&seville_port5 { + managed = "in-band-status"; + phy-handle = <&phy_qsgmii_5>; + phy-mode = "qsgmii"; + /* ETH9 written on chassis */ + label = "swp9"; + status = "okay"; +}; + +&seville_port6 { + managed = "in-band-status"; + phy-handle = <&phy_qsgmii_6>; + phy-mode = "qsgmii"; + /* ETH10 written on chassis */ + label = "swp10"; + status = "okay"; +}; + +&seville_port7 { + managed = "in-band-status"; + phy-handle = <&phy_qsgmii_7>; + phy-mode = "qsgmii"; + /* ETH11 written on chassis */ + label = "swp11"; + status = "okay"; +}; + +&seville_port8 { + ethernet = <&enet0>; + status = "okay"; +};