From: Vladimir Oltean <[email protected]>
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 <[email protected]>
---
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";
+};
--
2.25.1
Reviewed-by: Maxim Kochetkov <[email protected]>
29.09.2020 14:32, Vladimir Oltean пишет:
> From: Vladimir Oltean <[email protected]>
>
> 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 <[email protected]>
> ---
> 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