* [PATCH v2 2/2] ARM: dts: ls1021: Fix SGMII PCS link remaining down after PHY disconnect
@ 2019-04-11 23:23 ` Vladimir Oltean
0 siblings, 0 replies; 11+ messages in thread
From: Vladimir Oltean @ 2019-04-11 23:23 UTC (permalink / raw)
To: shawnguo, leoyang.li, claudiu.manoil
Cc: devicetree, netdev, linux-kernel, robh+dt, Vladimir Oltean,
davem, linux-arm-kernel
Each eTSEC MAC has its own TBI (SGMII) PCS and private MDIO bus.
But due to a DTS oversight, both SGMII-compatible MACs of the LS1021 SoC
are pointing towards the same internal PCS. Therefore nobody is
controlling the internal PCS of eTSEC0.
Upon initial ndo_open, the SGMII link is ok by virtue of U-boot
initialization. But upon an ifdown/ifup sequence, the code path from
ndo_open -> init_phy -> gfar_configure_serdes does not get executed for
the PCS of eTSEC0 (and is executed twice for MAC eTSEC1). So the SGMII
link remains down for eTSEC0. On the LS1021A-TWR board, to signal this
failure condition, the PHY driver keeps printing
'803x_aneg_done: SGMII link is not ok'.
Fixes: 055223d4d22d ("ARM: dts: ls1021a: Enable the eTSEC ports on QDS and TWR")
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
arch/arm/boot/dts/ls1021a-twr.dts | 9 ++++++++-
arch/arm/boot/dts/ls1021a.dtsi | 9 +++++++++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
index 97e1fb7ea932..9b1fe99d55b1 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -145,7 +145,7 @@
};
&enet0 {
- tbi-handle = <&tbi1>;
+ tbi-handle = <&tbi0>;
phy-handle = <&sgmii_phy2>;
phy-connection-type = "sgmii";
status = "okay";
@@ -225,6 +225,13 @@
sgmii_phy2: ethernet-phy@2 {
reg = <0x2>;
};
+ tbi0: tbi-phy@1f {
+ reg = <0x1f>;
+ device_type = "tbi-phy";
+ };
+};
+
+&mdio1 {
tbi1: tbi-phy@1f {
reg = <0x1f>;
device_type = "tbi-phy";
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 1a2a9509d9c2..89eab1fd1f7f 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -709,6 +709,15 @@
<0x0 0x2d10030 0x0 0x4>;
};
+ mdio1: mdio@2d64000 {
+ compatible = "fsl,etsec2-mdio";
+ device_type = "mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2d64000 0x0 0x4000>,
+ <0x0 0x2d50030 0x0 0x4>;
+ };
+
ptp_clock@2d10e00 {
compatible = "fsl,etsec-ptp";
reg = <0x0 0x2d10e00 0x0 0xb0>;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v2 2/2] ARM: dts: ls1021: Fix SGMII PCS link remaining down after PHY disconnect
2019-04-11 23:23 ` Vladimir Oltean
@ 2019-04-16 10:51 ` Vladimir Oltean
-1 siblings, 0 replies; 11+ messages in thread
From: Vladimir Oltean @ 2019-04-16 10:51 UTC (permalink / raw)
To: shawnguo, leoyang.li, Claudiu Manoil
Cc: robh+dt, linux-arm-kernel, devicetree, linux-kernel, netdev, davem
On Fri, 12 Apr 2019 at 02:27, Vladimir Oltean <olteanv@gmail.com> wrote:
>
> Each eTSEC MAC has its own TBI (SGMII) PCS and private MDIO bus.
> But due to a DTS oversight, both SGMII-compatible MACs of the LS1021 SoC
> are pointing towards the same internal PCS. Therefore nobody is
> controlling the internal PCS of eTSEC0.
>
> Upon initial ndo_open, the SGMII link is ok by virtue of U-boot
> initialization. But upon an ifdown/ifup sequence, the code path from
> ndo_open -> init_phy -> gfar_configure_serdes does not get executed for
> the PCS of eTSEC0 (and is executed twice for MAC eTSEC1). So the SGMII
> link remains down for eTSEC0. On the LS1021A-TWR board, to signal this
> failure condition, the PHY driver keeps printing
> '803x_aneg_done: SGMII link is not ok'.
>
> Fixes: 055223d4d22d ("ARM: dts: ls1021a: Enable the eTSEC ports on QDS and TWR")
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> ---
> arch/arm/boot/dts/ls1021a-twr.dts | 9 ++++++++-
> arch/arm/boot/dts/ls1021a.dtsi | 9 +++++++++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
> index 97e1fb7ea932..9b1fe99d55b1 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -145,7 +145,7 @@
> };
>
> &enet0 {
> - tbi-handle = <&tbi1>;
> + tbi-handle = <&tbi0>;
> phy-handle = <&sgmii_phy2>;
> phy-connection-type = "sgmii";
> status = "okay";
> @@ -225,6 +225,13 @@
> sgmii_phy2: ethernet-phy@2 {
> reg = <0x2>;
> };
> + tbi0: tbi-phy@1f {
> + reg = <0x1f>;
> + device_type = "tbi-phy";
> + };
> +};
> +
> +&mdio1 {
> tbi1: tbi-phy@1f {
> reg = <0x1f>;
> device_type = "tbi-phy";
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 1a2a9509d9c2..89eab1fd1f7f 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -709,6 +709,15 @@
> <0x0 0x2d10030 0x0 0x4>;
> };
>
> + mdio1: mdio@2d64000 {
> + compatible = "fsl,etsec2-mdio";
> + device_type = "mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2d64000 0x0 0x4000>,
> + <0x0 0x2d50030 0x0 0x4>;
> + };
> +
> ptp_clock@2d10e00 {
> compatible = "fsl,etsec-ptp";
> reg = <0x0 0x2d10e00 0x0 0xb0>;
> --
> 2.17.1
>
Hi Leo,
Just a reminder that I resent this patch rebased on top of the
compatible string change.
Thanks,
-Vladimir
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v2 2/2] ARM: dts: ls1021: Fix SGMII PCS link remaining down after PHY disconnect
@ 2019-04-16 10:51 ` Vladimir Oltean
0 siblings, 0 replies; 11+ messages in thread
From: Vladimir Oltean @ 2019-04-16 10:51 UTC (permalink / raw)
To: shawnguo, leoyang.li, Claudiu Manoil
Cc: devicetree, netdev, linux-kernel, robh+dt, davem, linux-arm-kernel
On Fri, 12 Apr 2019 at 02:27, Vladimir Oltean <olteanv@gmail.com> wrote:
>
> Each eTSEC MAC has its own TBI (SGMII) PCS and private MDIO bus.
> But due to a DTS oversight, both SGMII-compatible MACs of the LS1021 SoC
> are pointing towards the same internal PCS. Therefore nobody is
> controlling the internal PCS of eTSEC0.
>
> Upon initial ndo_open, the SGMII link is ok by virtue of U-boot
> initialization. But upon an ifdown/ifup sequence, the code path from
> ndo_open -> init_phy -> gfar_configure_serdes does not get executed for
> the PCS of eTSEC0 (and is executed twice for MAC eTSEC1). So the SGMII
> link remains down for eTSEC0. On the LS1021A-TWR board, to signal this
> failure condition, the PHY driver keeps printing
> '803x_aneg_done: SGMII link is not ok'.
>
> Fixes: 055223d4d22d ("ARM: dts: ls1021a: Enable the eTSEC ports on QDS and TWR")
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> ---
> arch/arm/boot/dts/ls1021a-twr.dts | 9 ++++++++-
> arch/arm/boot/dts/ls1021a.dtsi | 9 +++++++++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
> index 97e1fb7ea932..9b1fe99d55b1 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -145,7 +145,7 @@
> };
>
> &enet0 {
> - tbi-handle = <&tbi1>;
> + tbi-handle = <&tbi0>;
> phy-handle = <&sgmii_phy2>;
> phy-connection-type = "sgmii";
> status = "okay";
> @@ -225,6 +225,13 @@
> sgmii_phy2: ethernet-phy@2 {
> reg = <0x2>;
> };
> + tbi0: tbi-phy@1f {
> + reg = <0x1f>;
> + device_type = "tbi-phy";
> + };
> +};
> +
> +&mdio1 {
> tbi1: tbi-phy@1f {
> reg = <0x1f>;
> device_type = "tbi-phy";
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 1a2a9509d9c2..89eab1fd1f7f 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -709,6 +709,15 @@
> <0x0 0x2d10030 0x0 0x4>;
> };
>
> + mdio1: mdio@2d64000 {
> + compatible = "fsl,etsec2-mdio";
> + device_type = "mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2d64000 0x0 0x4000>,
> + <0x0 0x2d50030 0x0 0x4>;
> + };
> +
> ptp_clock@2d10e00 {
> compatible = "fsl,etsec-ptp";
> reg = <0x0 0x2d10e00 0x0 0xb0>;
> --
> 2.17.1
>
Hi Leo,
Just a reminder that I resent this patch rebased on top of the
compatible string change.
Thanks,
-Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: ls1021: Fix SGMII PCS link remaining down after PHY disconnect
2019-04-11 23:23 ` Vladimir Oltean
(?)
@ 2019-04-16 16:57 ` Li Yang
-1 siblings, 0 replies; 11+ messages in thread
From: Li Yang @ 2019-04-16 16:57 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Shawn Guo, claudiu.manoil, Rob Herring,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, lkml,
Netdev, David Miller
On Thu, Apr 11, 2019 at 6:28 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> Each eTSEC MAC has its own TBI (SGMII) PCS and private MDIO bus.
> But due to a DTS oversight, both SGMII-compatible MACs of the LS1021 SoC
> are pointing towards the same internal PCS. Therefore nobody is
> controlling the internal PCS of eTSEC0.
>
> Upon initial ndo_open, the SGMII link is ok by virtue of U-boot
> initialization. But upon an ifdown/ifup sequence, the code path from
> ndo_open -> init_phy -> gfar_configure_serdes does not get executed for
> the PCS of eTSEC0 (and is executed twice for MAC eTSEC1). So the SGMII
> link remains down for eTSEC0. On the LS1021A-TWR board, to signal this
> failure condition, the PHY driver keeps printing
> '803x_aneg_done: SGMII link is not ok'.
>
> Fixes: 055223d4d22d ("ARM: dts: ls1021a: Enable the eTSEC ports on QDS and TWR")
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
Thanks,
Leo
> ---
> arch/arm/boot/dts/ls1021a-twr.dts | 9 ++++++++-
> arch/arm/boot/dts/ls1021a.dtsi | 9 +++++++++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
> index 97e1fb7ea932..9b1fe99d55b1 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -145,7 +145,7 @@
> };
>
> &enet0 {
> - tbi-handle = <&tbi1>;
> + tbi-handle = <&tbi0>;
> phy-handle = <&sgmii_phy2>;
> phy-connection-type = "sgmii";
> status = "okay";
> @@ -225,6 +225,13 @@
> sgmii_phy2: ethernet-phy@2 {
> reg = <0x2>;
> };
> + tbi0: tbi-phy@1f {
> + reg = <0x1f>;
> + device_type = "tbi-phy";
> + };
> +};
> +
> +&mdio1 {
> tbi1: tbi-phy@1f {
> reg = <0x1f>;
> device_type = "tbi-phy";
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 1a2a9509d9c2..89eab1fd1f7f 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -709,6 +709,15 @@
> <0x0 0x2d10030 0x0 0x4>;
> };
>
> + mdio1: mdio@2d64000 {
> + compatible = "fsl,etsec2-mdio";
> + device_type = "mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2d64000 0x0 0x4000>,
> + <0x0 0x2d50030 0x0 0x4>;
> + };
> +
> ptp_clock@2d10e00 {
> compatible = "fsl,etsec-ptp";
> reg = <0x0 0x2d10e00 0x0 0xb0>;
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v2 2/2] ARM: dts: ls1021: Fix SGMII PCS link remaining down after PHY disconnect
@ 2019-04-16 16:57 ` Li Yang
0 siblings, 0 replies; 11+ messages in thread
From: Li Yang @ 2019-04-16 16:57 UTC (permalink / raw)
To: Vladimir Oltean
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Netdev, lkml, claudiu.manoil, Rob Herring, Shawn Guo,
David Miller,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
On Thu, Apr 11, 2019 at 6:28 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> Each eTSEC MAC has its own TBI (SGMII) PCS and private MDIO bus.
> But due to a DTS oversight, both SGMII-compatible MACs of the LS1021 SoC
> are pointing towards the same internal PCS. Therefore nobody is
> controlling the internal PCS of eTSEC0.
>
> Upon initial ndo_open, the SGMII link is ok by virtue of U-boot
> initialization. But upon an ifdown/ifup sequence, the code path from
> ndo_open -> init_phy -> gfar_configure_serdes does not get executed for
> the PCS of eTSEC0 (and is executed twice for MAC eTSEC1). So the SGMII
> link remains down for eTSEC0. On the LS1021A-TWR board, to signal this
> failure condition, the PHY driver keeps printing
> '803x_aneg_done: SGMII link is not ok'.
>
> Fixes: 055223d4d22d ("ARM: dts: ls1021a: Enable the eTSEC ports on QDS and TWR")
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
Thanks,
Leo
> ---
> arch/arm/boot/dts/ls1021a-twr.dts | 9 ++++++++-
> arch/arm/boot/dts/ls1021a.dtsi | 9 +++++++++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
> index 97e1fb7ea932..9b1fe99d55b1 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -145,7 +145,7 @@
> };
>
> &enet0 {
> - tbi-handle = <&tbi1>;
> + tbi-handle = <&tbi0>;
> phy-handle = <&sgmii_phy2>;
> phy-connection-type = "sgmii";
> status = "okay";
> @@ -225,6 +225,13 @@
> sgmii_phy2: ethernet-phy@2 {
> reg = <0x2>;
> };
> + tbi0: tbi-phy@1f {
> + reg = <0x1f>;
> + device_type = "tbi-phy";
> + };
> +};
> +
> +&mdio1 {
> tbi1: tbi-phy@1f {
> reg = <0x1f>;
> device_type = "tbi-phy";
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 1a2a9509d9c2..89eab1fd1f7f 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -709,6 +709,15 @@
> <0x0 0x2d10030 0x0 0x4>;
> };
>
> + mdio1: mdio@2d64000 {
> + compatible = "fsl,etsec2-mdio";
> + device_type = "mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2d64000 0x0 0x4000>,
> + <0x0 0x2d50030 0x0 0x4>;
> + };
> +
> ptp_clock@2d10e00 {
> compatible = "fsl,etsec-ptp";
> reg = <0x0 0x2d10e00 0x0 0xb0>;
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v2 2/2] ARM: dts: ls1021: Fix SGMII PCS link remaining down after PHY disconnect
@ 2019-04-16 16:57 ` Li Yang
0 siblings, 0 replies; 11+ messages in thread
From: Li Yang @ 2019-04-16 16:57 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Shawn Guo, claudiu.manoil, Rob Herring,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, lkml,
Netdev, David Miller
On Thu, Apr 11, 2019 at 6:28 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> Each eTSEC MAC has its own TBI (SGMII) PCS and private MDIO bus.
> But due to a DTS oversight, both SGMII-compatible MACs of the LS1021 SoC
> are pointing towards the same internal PCS. Therefore nobody is
> controlling the internal PCS of eTSEC0.
>
> Upon initial ndo_open, the SGMII link is ok by virtue of U-boot
> initialization. But upon an ifdown/ifup sequence, the code path from
> ndo_open -> init_phy -> gfar_configure_serdes does not get executed for
> the PCS of eTSEC0 (and is executed twice for MAC eTSEC1). So the SGMII
> link remains down for eTSEC0. On the LS1021A-TWR board, to signal this
> failure condition, the PHY driver keeps printing
> '803x_aneg_done: SGMII link is not ok'.
>
> Fixes: 055223d4d22d ("ARM: dts: ls1021a: Enable the eTSEC ports on QDS and TWR")
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
Thanks,
Leo
> ---
> arch/arm/boot/dts/ls1021a-twr.dts | 9 ++++++++-
> arch/arm/boot/dts/ls1021a.dtsi | 9 +++++++++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
> index 97e1fb7ea932..9b1fe99d55b1 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -145,7 +145,7 @@
> };
>
> &enet0 {
> - tbi-handle = <&tbi1>;
> + tbi-handle = <&tbi0>;
> phy-handle = <&sgmii_phy2>;
> phy-connection-type = "sgmii";
> status = "okay";
> @@ -225,6 +225,13 @@
> sgmii_phy2: ethernet-phy@2 {
> reg = <0x2>;
> };
> + tbi0: tbi-phy@1f {
> + reg = <0x1f>;
> + device_type = "tbi-phy";
> + };
> +};
> +
> +&mdio1 {
> tbi1: tbi-phy@1f {
> reg = <0x1f>;
> device_type = "tbi-phy";
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 1a2a9509d9c2..89eab1fd1f7f 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -709,6 +709,15 @@
> <0x0 0x2d10030 0x0 0x4>;
> };
>
> + mdio1: mdio@2d64000 {
> + compatible = "fsl,etsec2-mdio";
> + device_type = "mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2d64000 0x0 0x4000>,
> + <0x0 0x2d50030 0x0 0x4>;
> + };
> +
> ptp_clock@2d10e00 {
> compatible = "fsl,etsec-ptp";
> reg = <0x0 0x2d10e00 0x0 0xb0>;
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: ls1021: Fix SGMII PCS link remaining down after PHY disconnect
2019-04-11 23:23 ` Vladimir Oltean
@ 2019-04-21 7:59 ` Shawn Guo
-1 siblings, 0 replies; 11+ messages in thread
From: Shawn Guo @ 2019-04-21 7:59 UTC (permalink / raw)
To: Vladimir Oltean
Cc: leoyang.li, claudiu.manoil, robh+dt, linux-arm-kernel,
devicetree, linux-kernel, netdev, davem
On Fri, Apr 12, 2019 at 02:23:15AM +0300, Vladimir Oltean wrote:
> Each eTSEC MAC has its own TBI (SGMII) PCS and private MDIO bus.
> But due to a DTS oversight, both SGMII-compatible MACs of the LS1021 SoC
> are pointing towards the same internal PCS. Therefore nobody is
> controlling the internal PCS of eTSEC0.
>
> Upon initial ndo_open, the SGMII link is ok by virtue of U-boot
> initialization. But upon an ifdown/ifup sequence, the code path from
> ndo_open -> init_phy -> gfar_configure_serdes does not get executed for
> the PCS of eTSEC0 (and is executed twice for MAC eTSEC1). So the SGMII
> link remains down for eTSEC0. On the LS1021A-TWR board, to signal this
> failure condition, the PHY driver keeps printing
> '803x_aneg_done: SGMII link is not ok'.
>
> Fixes: 055223d4d22d ("ARM: dts: ls1021a: Enable the eTSEC ports on QDS and TWR")
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
To get it land as fix a bit easier, I squashed both patches into one
(with a little edit on commit log), and applied it.
Shawn
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v2 2/2] ARM: dts: ls1021: Fix SGMII PCS link remaining down after PHY disconnect
@ 2019-04-21 7:59 ` Shawn Guo
0 siblings, 0 replies; 11+ messages in thread
From: Shawn Guo @ 2019-04-21 7:59 UTC (permalink / raw)
To: Vladimir Oltean
Cc: devicetree, netdev, linux-kernel, leoyang.li, claudiu.manoil,
robh+dt, davem, linux-arm-kernel
On Fri, Apr 12, 2019 at 02:23:15AM +0300, Vladimir Oltean wrote:
> Each eTSEC MAC has its own TBI (SGMII) PCS and private MDIO bus.
> But due to a DTS oversight, both SGMII-compatible MACs of the LS1021 SoC
> are pointing towards the same internal PCS. Therefore nobody is
> controlling the internal PCS of eTSEC0.
>
> Upon initial ndo_open, the SGMII link is ok by virtue of U-boot
> initialization. But upon an ifdown/ifup sequence, the code path from
> ndo_open -> init_phy -> gfar_configure_serdes does not get executed for
> the PCS of eTSEC0 (and is executed twice for MAC eTSEC1). So the SGMII
> link remains down for eTSEC0. On the LS1021A-TWR board, to signal this
> failure condition, the PHY driver keeps printing
> '803x_aneg_done: SGMII link is not ok'.
>
> Fixes: 055223d4d22d ("ARM: dts: ls1021a: Enable the eTSEC ports on QDS and TWR")
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
To get it land as fix a bit easier, I squashed both patches into one
(with a little edit on commit log), and applied it.
Shawn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 11+ messages in thread