Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
This adds a phy node to the MicroSoM DTS and a 100Mb/s max-speed limit
to the Cubox-i Solo/DualLite carrier DTS.
Signed-off-by: tinywrkb <[email protected]>
---
This patch fixes ethernet on my Cubox-i2-300-D which is limited to 100Mb/s,
afaik due to the carrier board magnetics, and was since commit 5502b218e001
("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
The AR8035 PHY on the CPU module reports to the driver as 1GbE capable
via MII_BSMR's BMSR_ESTATEN status bit, the auto-negotiation sets the
speed at 1GbE while the carrier board can't support it.
Same behavior with the generic phy_device and the at803x drivers.
While the PHY is on the CPU module board I added the max-speed limit to
the cubox-i carrier DTS as I suspect that if the Solo or DualLite v1.3
MicroSoM will be connected to a 1GbE capable carrier board then it would
work correctly with 1GbE.
I can confirm that this commit doesn't break networking on the my
Cubox-i4Pro Quad (i4P-300-D) with it's 1GbE capable carrier board, and
was tested separately with the generic phy_device and at803x drivers.
arch/arm/boot/dts/imx6dl-cubox-i.dts | 4 ++++
arch/arm/boot/dts/imx6qdl-sr-som.dtsi | 9 +++++++++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-cubox-i.dts b/arch/arm/boot/dts/imx6dl-cubox-i.dts
index 2b1b3e193f53..cfc82513c78c 100644
--- a/arch/arm/boot/dts/imx6dl-cubox-i.dts
+++ b/arch/arm/boot/dts/imx6dl-cubox-i.dts
@@ -49,3 +49,7 @@
model = "SolidRun Cubox-i Solo/DualLite";
compatible = "solidrun,cubox-i/dl", "fsl,imx6dl";
};
+
+ðphy {
+ max-speed = <100>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
index 6d7f6b9035bc..969bc96c3f99 100644
--- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
@@ -57,6 +57,15 @@
phy-reset-duration = <2>;
phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
status = "okay";
+ phy-handle = <ðphy>;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethphy: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+ };
};
&iomuxc {
--
2.23.0
Hi tinywrkb,
On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote:
> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
According to the hardware designer, Rabeeh Khoury, there is not such
limitation in the Cubox-i carrier magnetics.
> Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
Does revert of 5502b218e001 fixes your issue?
> This adds a phy node to the MicroSoM DTS and a 100Mb/s max-speed limit
> to the Cubox-i Solo/DualLite carrier DTS.
>
> Signed-off-by: tinywrkb <[email protected]>
You must use your real name in sign-off.
> ---
> This patch fixes ethernet on my Cubox-i2-300-D which is limited to 100Mb/s,
> afaik due to the carrier board magnetics, and was since commit 5502b218e001
> ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
>
> The AR8035 PHY on the CPU module reports to the driver as 1GbE capable
> via MII_BSMR's BMSR_ESTATEN status bit, the auto-negotiation sets the
> speed at 1GbE while the carrier board can't support it.
> Same behavior with the generic phy_device and the at803x drivers.
>
> While the PHY is on the CPU module board I added the max-speed limit to
> the cubox-i carrier DTS as I suspect that if the Solo or DualLite v1.3
> MicroSoM will be connected to a 1GbE capable carrier board then it would
> work correctly with 1GbE.
>
> I can confirm that this commit doesn't break networking on the my
> Cubox-i4Pro Quad (i4P-300-D) with it's 1GbE capable carrier board, and
> was tested separately with the generic phy_device and at803x drivers.
>
> arch/arm/boot/dts/imx6dl-cubox-i.dts | 4 ++++
> arch/arm/boot/dts/imx6qdl-sr-som.dtsi | 9 +++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-cubox-i.dts b/arch/arm/boot/dts/imx6dl-cubox-i.dts
> index 2b1b3e193f53..cfc82513c78c 100644
> --- a/arch/arm/boot/dts/imx6dl-cubox-i.dts
> +++ b/arch/arm/boot/dts/imx6dl-cubox-i.dts
> @@ -49,3 +49,7 @@
> model = "SolidRun Cubox-i Solo/DualLite";
> compatible = "solidrun,cubox-i/dl", "fsl,imx6dl";
> };
> +
> +ðphy {
> + max-speed = <100>;
> +};
Where is the ethphy lable defined? Have you build tested this patch?
> diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> index 6d7f6b9035bc..969bc96c3f99 100644
> --- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> @@ -57,6 +57,15 @@
> phy-reset-duration = <2>;
> phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
> status = "okay";
> + phy-handle = <ðphy>;
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ethphy: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + };
> + };
> };
>
> &iomuxc {
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -
On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote:
> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
>
> Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
Hi Tinywrkb
You emailed lots of people, but missed the PHY maintainers :-(
Are you sure this is the patch which broken it? Did you do a git
bisect.
Thanks
Andrew
On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote:
> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
That statement is false, sorry. All boards support 1G.
> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
>
> Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
>
> This adds a phy node to the MicroSoM DTS and a 100Mb/s max-speed limit
> to the Cubox-i Solo/DualLite carrier DTS.
>
> Signed-off-by: tinywrkb <[email protected]>
> ---
> This patch fixes ethernet on my Cubox-i2-300-D which is limited to 100Mb/s,
> afaik due to the carrier board magnetics, and was since commit 5502b218e001
> ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
>
> The AR8035 PHY on the CPU module reports to the driver as 1GbE capable
> via MII_BSMR's BMSR_ESTATEN status bit, the auto-negotiation sets the
> speed at 1GbE while the carrier board can't support it.
> Same behavior with the generic phy_device and the at803x drivers.
>
> While the PHY is on the CPU module board I added the max-speed limit to
> the cubox-i carrier DTS as I suspect that if the Solo or DualLite v1.3
> MicroSoM will be connected to a 1GbE capable carrier board then it would
> work correctly with 1GbE.
>
> I can confirm that this commit doesn't break networking on the my
> Cubox-i4Pro Quad (i4P-300-D) with it's 1GbE capable carrier board, and
> was tested separately with the generic phy_device and at803x drivers.
>
> arch/arm/boot/dts/imx6dl-cubox-i.dts | 4 ++++
> arch/arm/boot/dts/imx6qdl-sr-som.dtsi | 9 +++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-cubox-i.dts b/arch/arm/boot/dts/imx6dl-cubox-i.dts
> index 2b1b3e193f53..cfc82513c78c 100644
> --- a/arch/arm/boot/dts/imx6dl-cubox-i.dts
> +++ b/arch/arm/boot/dts/imx6dl-cubox-i.dts
> @@ -49,3 +49,7 @@
> model = "SolidRun Cubox-i Solo/DualLite";
> compatible = "solidrun,cubox-i/dl", "fsl,imx6dl";
> };
> +
> +ðphy {
> + max-speed = <100>;
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> index 6d7f6b9035bc..969bc96c3f99 100644
> --- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> @@ -57,6 +57,15 @@
> phy-reset-duration = <2>;
> phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
> status = "okay";
> + phy-handle = <ðphy>;
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ethphy: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + };
> + };
> };
>
> &iomuxc {
> --
> 2.23.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Hi Andrew,
On Tue, Sep 10 2019, Andrew Lunn wrote:
> On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote:
>> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
>> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
>>
>> Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
>> genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
>
> Hi Tinywrkb
>
> You emailed lots of people, but missed the PHY maintainers :-(
>
> Are you sure this is the patch which broken it? Did you do a git
> bisect.
Tinywrkb confirmed to me in private communication that revert of
5502b218e001 fixes Ethernet for him on effected system.
He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
there was a plan to use a different 10/100 PHY for Solo/DualLite
SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
AR8035 PHY that supports 1Gb.
Commit 5502b218e001 might be triggering a hardware issue on the affected
Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
the moment.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.52.368.4656, http://www.tkos.co.il -
On Sun, Sep 15, 2019 at 09:30:00AM +0300, Baruch Siach wrote:
> Hi Andrew,
>
> On Tue, Sep 10 2019, Andrew Lunn wrote:
> > On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote:
> >> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
> >> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
> >>
> >> Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> >> genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
> >
> > Hi Tinywrkb
> >
> > You emailed lots of people, but missed the PHY maintainers :-(
> >
> > Are you sure this is the patch which broken it? Did you do a git
> > bisect.
>
> Tinywrkb confirmed to me in private communication that revert of
> 5502b218e001 fixes Ethernet for him on effected system.
>
> He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> there was a plan to use a different 10/100 PHY for Solo/DualLite
> SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> AR8035 PHY that supports 1Gb.
>
> Commit 5502b218e001 might be triggering a hardware issue on the affected
> Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> the moment.
With 5.3 due out today, I'll be updating my systems to that, which will
include quite a few variants of the Hummingboard.
It looks like one of my Solo Hummingboards (running a fully up to date
Fedora 28) has encountered a problem, so needs a reboot...
systemd-journald[436]: Failed to retrieve credentials for PID 17906, ignoring: Cannot allocate memory
systemd-journald[436]: Failed to open runtime journal: Cannot allocate memory
# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
...
root 436 0.0 5.2 3128140 26392 ? Ss Aug03 1:20 /usr/lib/systemd/systemd-journald
# uptime
13:28:41 up 42 days, 19:13, 1 user, load average: 0.00, 0.03, 0.00
Looks like systemd-journald has a rather bad memory leak...
#include <std-complaints-about-systemd>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
> Tinywrkb confirmed to me in private communication that revert of
> 5502b218e001 fixes Ethernet for him on effected system.
>
> He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> there was a plan to use a different 10/100 PHY for Solo/DualLite
> SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> AR8035 PHY that supports 1Gb.
>
> Commit 5502b218e001 might be triggering a hardware issue on the affected
> Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> the moment.
Could somebody with an affected device show us the output of ethtool
with and without 5502b218e001. Does one show 1G has been negotiated,
and the other 100Mbps? If this is true, how does it get 100Mbps
without that patch? We are missing a piece of the puzzle.
Andrew
On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > Tinywrkb confirmed to me in private communication that revert of
> > 5502b218e001 fixes Ethernet for him on effected system.
> >
> > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > AR8035 PHY that supports 1Gb.
> >
> > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > the moment.
>
> Could somebody with an affected device show us the output of ethtool
> with and without 5502b218e001. Does one show 1G has been negotiated,
> and the other 100Mbps? If this is true, how does it get 100Mbps
> without that patch? We are missing a piece of the puzzle.
Hang on. 5502b218e001 is in 5.2 already - it was merged as part of the
v5.1 merge window. That means my imx6 Solo Hummingboard is already
running it with the AR8035 PHY, and it works fine.
# dmesg
...
OF: fdt: Machine model: SolidRun HummingBoard Solo/DualLite
...
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Sun, Sep 15, 2019 at 03:06:39PM +0100, Russell King - ARM Linux admin wrote:
> On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > Tinywrkb confirmed to me in private communication that revert of
> > > 5502b218e001 fixes Ethernet for him on effected system.
> > >
> > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > AR8035 PHY that supports 1Gb.
> > >
> > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > the moment.
> >
> > Could somebody with an affected device show us the output of ethtool
> > with and without 5502b218e001. Does one show 1G has been negotiated,
> > and the other 100Mbps? If this is true, how does it get 100Mbps
> > without that patch? We are missing a piece of the puzzle.
>
> Hang on. 5502b218e001 is in 5.2 already - it was merged as part of the
> v5.1 merge window. That means my imx6 Solo Hummingboard is already
> running it with the AR8035 PHY, and it works fine.
>
> # dmesg
> ...
> OF: fdt: Machine model: SolidRun HummingBoard Solo/DualLite
> ...
> # ethtool eth0
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Supported pause frame use: Symmetric
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Link partner advertised pause frame use: Symmetric
> Link partner advertised auto-negotiation: Yes
> Link partner advertised FEC modes: Not reported
> Speed: 1000Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 0
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: d
> Wake-on: d
> Link detected: yes
For some further testing, by changing the advertisment on the DSA
switch (other end of this platform's link):
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
...
Speed: 100Mb/s
Duplex: Full
===============
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half
...
Speed: 100Mb/s
Duplex: Half
===============
Link partner advertised link modes: 10baseT/Half 10baseT/Full
...
Speed: 10Mb/s
Duplex: Full
===============
Link partner advertised link modes: 10baseT/Half
...
Speed: 10Mb/s
Duplex: Half
So it looks like the commit works as it should. So there's something
else going on.
Note that the FEC does *not* support 1000baseT/Half.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
> > OF: fdt: Machine model: SolidRun HummingBoard Solo/DualLite
> > ...
> > # ethtool eth0
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Supported pause frame use: Symmetric
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Advertised pause frame use: Symmetric
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Link partner advertised pause frame use: Symmetric
> > Link partner advertised auto-negotiation: Yes
> > Link partner advertised FEC modes: Not reported
> > Speed: 1000Mb/s
> > Duplex: Full
> > Port: MII
> > PHYAD: 0
> > Transceiver: internal
> > Auto-negotiation: on
> > Supports Wake-on: d
> > Wake-on: d
> > Link detected: yes
> Note that the FEC does *not* support 1000baseT/Half.
Hi Russell
fec_main.c has code to mask it out. And it is not listed in the modes
you have above. So as you say, this all looks to be working.
I'm wondering if there is an older variant of the hardware with
100Mbps magnetics, and the boot loader is setting something in the
PHY? It could be we are now stomping over that?
We need to see output like yours, but on a device which is
experiencing the problem.
Andrew
On Sun, Sep 15, 2019 at 04:42:52PM +0200, Andrew Lunn wrote:
> > > OF: fdt: Machine model: SolidRun HummingBoard Solo/DualLite
> > > ...
> > > # ethtool eth0
> > > Settings for eth0:
> > > Supported ports: [ TP MII ]
> > > Supported link modes: 10baseT/Half 10baseT/Full
> > > 100baseT/Half 100baseT/Full
> > > 1000baseT/Full
> > > Supported pause frame use: Symmetric
> > > Supports auto-negotiation: Yes
> > > Supported FEC modes: Not reported
> > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > 100baseT/Half 100baseT/Full
> > > 1000baseT/Full
> > > Advertised pause frame use: Symmetric
> > > Advertised auto-negotiation: Yes
> > > Advertised FEC modes: Not reported
> > > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > > 100baseT/Half 100baseT/Full
> > > 1000baseT/Full
> > > Link partner advertised pause frame use: Symmetric
> > > Link partner advertised auto-negotiation: Yes
> > > Link partner advertised FEC modes: Not reported
> > > Speed: 1000Mb/s
> > > Duplex: Full
> > > Port: MII
> > > PHYAD: 0
> > > Transceiver: internal
> > > Auto-negotiation: on
> > > Supports Wake-on: d
> > > Wake-on: d
> > > Link detected: yes
>
> > Note that the FEC does *not* support 1000baseT/Half.
>
> Hi Russell
>
> fec_main.c has code to mask it out. And it is not listed in the modes
> you have above. So as you say, this all looks to be working.
>
> I'm wondering if there is an older variant of the hardware with
> 100Mbps magnetics, and the boot loader is setting something in the
> PHY? It could be we are now stomping over that?
Not according to Rabeeh, the SolidRun CTO:
< rabeeh> all i.MX6 based machines from SolidRun are 1Gbps phys
< rabeeh> i thought that we fixed that information, documentation wise;
but seems not
Even the Carrier1 board that pre-dates Hummingboards had the AR8035
with 1G magnetics.
The schematics I have for the Cubox-i state that the RJ45 jack (which
contains the magnetics) is to be "Gigabit".
There was a 10/100M option for the microsom, which is selected by where
a resistor pack is fitted, having the effect of configuring the AR8035
differently. I seem to recall the 10/100M option in the early days was
to use a different Atheros PHY.
However, I'm not aware of 10/100M option making it into production, and
Rabeeh's comment (who was involved in the design) confirms that.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > Tinywrkb confirmed to me in private communication that revert of
> > 5502b218e001 fixes Ethernet for him on effected system.
> >
> > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > AR8035 PHY that supports 1Gb.
> >
> > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > the moment.
>
> Could somebody with an affected device show us the output of ethtool
> with and without 5502b218e001. Does one show 1G has been negotiated,
> and the other 100Mbps? If this is true, how does it get 100Mbps
> without that patch? We are missing a piece of the puzzle.
>
> Andrew
linux-test-5.1rc1-a2703de70942-without_bad_commit
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
journalctl -b | egrep -i 'phy|eth|fec'|grep -v usb
kernel: Booting Linux on physical CPU 0x0
kernel: libphy: Fixed MDIO Bus: probed
kernel: libphy: fec_enet_mii_bus: probed
kernel: fec 2188000.ethernet eth0: registered PHC device 0
kernel: dwhdmi-imx 120000.hdmi: Detected HDMI TX controller v1.31a with HDCP (DWC HDMI 3D TX PHY)
kernel: Generic PHY 2188000.ethernet-1:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
kernel: fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
systemd-networkd[243]: eth0: Gained carrier
systemd-networkd[243]: eth0: DHCPv4 address 192.168.15.101/24 via 192.168.15.1
systemd-networkd[243]: eth0: Gained IPv6LL
systemd-networkd[243]: eth0: Configured
######################################################################
linux-test-5.1rc1-5502b218e001-with_bad_commit
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
journalctl -b | egrep -i 'phy|eth|fec'|grep -v usb
kernel: Booting Linux on physical CPU 0x0
kernel: libphy: Fixed MDIO Bus: probed
kernel: libphy: fec_enet_mii_bus: probed
kernel: fec 2188000.ethernet eth0: registered PHC device 0
kernel: dwhdmi-imx 120000.hdmi: Detected HDMI TX controller v1.31a with HDCP (DWC HDMI 3D TX PHY)
kernel: Generic PHY 2188000.ethernet-1:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
kernel: fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
systemd-networkd[239]: eth0: Gained carrier
systemd-networkd[239]: eth0: Gained IPv6LL
On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > Tinywrkb confirmed to me in private communication that revert of
> > > 5502b218e001 fixes Ethernet for him on effected system.
> > >
> > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > AR8035 PHY that supports 1Gb.
> > >
> > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > the moment.
> >
> > Could somebody with an affected device show us the output of ethtool
> > with and without 5502b218e001. Does one show 1G has been negotiated,
> > and the other 100Mbps? If this is true, how does it get 100Mbps
> > without that patch? We are missing a piece of the puzzle.
> >
> > Andrew
>
> linux-test-5.1rc1-a2703de70942-without_bad_commit
>
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
So this means the local device says it can do 1000Mbps.
> Supported pause frame use: Symmetric
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
The link peer can also do 1000Mbps.
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Link partner advertised pause frame use: Symmetric
> Link partner advertised auto-negotiation: Yes
> Link partner advertised FEC modes: Not reported
> Speed: 100Mb/s
Yet they have decided to do 100Mbps.
We need to understand Why? The generic PHY driver would not do this on
its own. So i'm thinking something has poked a PHY register with some
value, and this patch is causing it to be over written.
Please can you use mii-tool -v -v to dump the PHY registers in each
case.
Thanks
Andrew
On Tue, Sep 17, 2019 at 02:54:34PM +0200, Andrew Lunn wrote:
> On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> > On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > > Tinywrkb confirmed to me in private communication that revert of
> > > > 5502b218e001 fixes Ethernet for him on effected system.
> > > >
> > > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > > AR8035 PHY that supports 1Gb.
> > > >
> > > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > > the moment.
> > >
> > > Could somebody with an affected device show us the output of ethtool
> > > with and without 5502b218e001. Does one show 1G has been negotiated,
> > > and the other 100Mbps? If this is true, how does it get 100Mbps
> > > without that patch? We are missing a piece of the puzzle.
> > >
> > > Andrew
> >
> > linux-test-5.1rc1-a2703de70942-without_bad_commit
> >
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
>
> So this means the local device says it can do 1000Mbps.
>
>
> > Supported pause frame use: Symmetric
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
>
> The link peer can also do 1000Mbps.
>
>
> > Advertised pause frame use: Symmetric
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Link partner advertised pause frame use: Symmetric
> > Link partner advertised auto-negotiation: Yes
> > Link partner advertised FEC modes: Not reported
> > Speed: 100Mb/s
>
> Yet they have decided to do 100Mbps.
>
> We need to understand Why? The generic PHY driver would not do this on
> its own. So i'm thinking something has poked a PHY register with some
> value, and this patch is causing it to be over written.
>
> Please can you use mii-tool -v -v to dump the PHY registers in each
> case.
>
> Thanks
> Andrew
Here's the output of # mii-tool -v -v eth0
* linux-test-5.1rc1-a2703de70942-without_bad_commit
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD flow-control, link ok
registers for MII PHY 0:
3100 796d 004d d072 15e1 c5e1 000f 0000
0000 0000 0800 0000 0000 0000 0000 a000
0000 0000 0000 f420 082c 0000 04e8 0000
3200 3000 0000 063d 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
* linux-test-5.1rc1-5502b218e001-with_bad_commit
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD flow-control, link ok
registers for MII PHY 0:
3100 796d 004d d072 15e1 c5e1 000d 0000
0000 0000 0800 0000 0000 0000 0000 a000
0000 0000 0000 0000 082c 0000 04e8 0000
3200 3000 0000 063d 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Thanks for helping Andrew.
On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> On Tue, Sep 17, 2019 at 02:54:34PM +0200, Andrew Lunn wrote:
> > On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> > > On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > > > Tinywrkb confirmed to me in private communication that revert of
> > > > > 5502b218e001 fixes Ethernet for him on effected system.
> > > > >
> > > > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > > > AR8035 PHY that supports 1Gb.
> > > > >
> > > > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > > > the moment.
> > > >
> > > > Could somebody with an affected device show us the output of ethtool
> > > > with and without 5502b218e001. Does one show 1G has been negotiated,
> > > > and the other 100Mbps? If this is true, how does it get 100Mbps
> > > > without that patch? We are missing a piece of the puzzle.
> > > >
> > > > Andrew
> > >
> > > linux-test-5.1rc1-a2703de70942-without_bad_commit
> > >
> > > Settings for eth0:
> > > Supported ports: [ TP MII ]
> > > Supported link modes: 10baseT/Half 10baseT/Full
> > > 100baseT/Half 100baseT/Full
> > > 1000baseT/Full
> >
> > So this means the local device says it can do 1000Mbps.
> >
> >
> > > Supported pause frame use: Symmetric
> > > Supports auto-negotiation: Yes
> > > Supported FEC modes: Not reported
> > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > 100baseT/Half 100baseT/Full
> > > 1000baseT/Full
> >
> > The link peer can also do 1000Mbps.
> >
> >
> > > Advertised pause frame use: Symmetric
> > > Advertised auto-negotiation: Yes
> > > Advertised FEC modes: Not reported
> > > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > > 100baseT/Half 100baseT/Full
> > > 1000baseT/Full
> > > Link partner advertised pause frame use: Symmetric
> > > Link partner advertised auto-negotiation: Yes
> > > Link partner advertised FEC modes: Not reported
> > > Speed: 100Mb/s
> >
> > Yet they have decided to do 100Mbps.
> >
> > We need to understand Why? The generic PHY driver would not do this on
> > its own. So i'm thinking something has poked a PHY register with some
> > value, and this patch is causing it to be over written.
> >
> > Please can you use mii-tool -v -v to dump the PHY registers in each
> > case.
> >
> > Thanks
> > Andrew
>
> Here's the output of # mii-tool -v -v eth0
>
> * linux-test-5.1rc1-a2703de70942-without_bad_commit
>
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 100baseTx-FD flow-control, link ok
> registers for MII PHY 0:
> 3100 796d 004d d072 15e1 c5e1 000f 0000
> 0000 0000 0800 0000 0000 0000 0000 a000
> 0000 0000 0000 f420 082c 0000 04e8 0000
> 3200 3000 0000 063d 0000 0000 0000 0000
> product info: vendor 00:13:74, model 7 rev 2
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
This is *not* advertising 1000baseT modes (register 9).
>
>
> * linux-test-5.1rc1-5502b218e001-with_bad_commit
>
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 100baseTx-FD flow-control, link ok
> registers for MII PHY 0:
> 3100 796d 004d d072 15e1 c5e1 000d 0000
> 0000 0000 0800 0000 0000 0000 0000 a000
> 0000 0000 0000 0000 082c 0000 04e8 0000
> 3200 3000 0000 063d 0000 0000 0000 0000
> product info: vendor 00:13:74, model 7 rev 2
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Neither is this.
However, the kernel and phylib _thinks_ that it is. My guess is
something has rewritten the PHY registers from userspace, rather
than using ethtool to change the advertisment. The MAC is still
trying to operate at 1000Mbps (since that is what phylib resolved)
yet the link might be actually operating at 100Mbps - but for that
to happen, we should've seen the link go down and up again.
Odd.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Tue, Sep 17, 2019 at 06:04:19PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 07:34:27PM +0300, tinywrkb wrote:
> > The patch didn't fix the issue.
> >
> > # ethtool eth0
> >
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Supported pause frame use: Symmetric
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Advertised pause frame use: Symmetric
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Link partner advertised pause frame use: Symmetric
> > Link partner advertised auto-negotiation: Yes
> > Link partner advertised FEC modes: Not reported
> > Speed: 1000Mb/s
> > Duplex: Full
> > Port: MII
> > PHYAD: 0
> > Transceiver: internal
> > Auto-negotiation: on
> > Supports Wake-on: d
> > Wake-on: d
> > Link detected: yes
> >
> > # mii-tool -v -v eth0
> >
> > Using SIOCGMIIPHY=0x8947
> > eth0: negotiated 100baseTx-FD flow-control, link ok
> > registers for MII PHY 0:
> > 3100 796d 004d d072 15e1 c5e1 000f 0000
> > 0000 0000 0800 0000 0000 0000 0000 a000
> > 0000 0000 0000 f420 082c 0000 04e8 0000
> > 3200 3000 0000 063d 0000 0000 0000 0000
> > product info: vendor 00:13:74, model 7 rev 2
> > basic mode: autonegotiation enabled
> > basic status: autonegotiation complete, link ok
> > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> >
> > # journalctl -b | egrep -i 'phy|eth|fec'|grep -v usb
> >
> > kernel: Booting Linux on physical CPU 0x0
> > kernel: libphy: Fixed MDIO Bus: probed
> > kernel: libphy: fec_enet_mii_bus: probed
> > kernel: fec 2188000.ethernet eth0: registered PHC device 0
> > kernel: dwhdmi-imx 120000.hdmi: Detected HDMI TX controller v1.31a with HDCP (DWC HDMI 3D TX PHY)
> > kernel: Generic PHY 2188000.ethernet-1:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
> > kernel: fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> > kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > systemd-networkd[242]: eth0: Gained carrier
>
> Okay, so this is getting weird.
>
> ethtool still shows that 1000baseT/Full is being advertised, yet the
> PHY disagrees:
>
> 3100 796d 004d d072 15e1 c5e1 000f 0000
> 0000 0000 0800 0000 0000 0000 0000 a000
> ^^^^
> Gigabit control register, bits 9 should be set, but it's clear.
>
> Looking at the following registers, brings up another possibility what
> is going on:
>
> 0000 0000 0000 f420 082c 0000 04e8 0000
> ^^^^ ^^^^
>
> These two registers may provide a hint. Of the first register, which
> is the interrupt status register, bit 5 is set, indicating that a
> "smartspeed downgrade occurred". The second register is the smartspeed
> configuration, which basically says that the feature is enabled.
>
> Smartspeed is designed to allow the link to come up if two-pair CAT5
> cable is used (are you using a 4-pair or 2-pair cable?) by making the
> link fall back to 100mbit, or with CAT3 cable, 10mbit speeds. What
> isn't specified is whether it does this by clearing bits in the various
> advertisement registers.
>
> Given what you've said so far, I'd suggest that this is indeed the
> case - when smartspeed is triggered, advertisement bits are cleared by
> the PHY without the kernel's knowledge, leading to the kernel getting
> the speed resolution incorrect after 5502b218e001.
>
> There's another issue here - if smartspeed clears advertisement bits,
> then if you connect a 4-pair cable after having used a 2-pair cable,
> you'd still be limited to 100mbit. The ethtool output will be just
> as confusing.
>
> The only thing I can think we should do is to read-back the
> advertisement from the PHY whenever we read the rest of the status
> and update the phy->advertising mask, just like we do with the link
> partner advertisement.
This patch will disable smartspeed - could you see what happens, and
whether you can get the link to come up at all. You might need to see
whether wiggling the RJ45 helps (I've had that sort of thing with some
cables.)
You might also need "ethtool -s eth0 advertise ffcf" after trying that
if it doesn't work to take the gigabit speeds out of the advertisement.
Thanks.
drivers/net/phy/at803x.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index b3893347804d..85cf4a4a5e81 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -296,6 +296,11 @@ static int at803x_config_init(struct phy_device *phydev)
if (ret < 0)
return ret;
+ /* Disable smartspeed */
+ ret = phy_modify(phydev, 0x14, BIT(5), 0);
+ if (ret < 0)
+ return ret;
+
/* The RX and TX delay default is:
* after HW reset: RX delay enabled and TX delay disabled
* after SW reset: RX delay enabled, while TX delay retains the
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index b3893347804d..85cf4a4a5e81 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
Hi Russell
This won't work. In the kernel logs, you see
kernel: Generic PHY 2188000.ethernet-1:00: attached PHY driver [Generic PHY]
The generic PHY driver is being used, not the at803x driver.
But i do like your idea, it does fit the problem description.
Andrew
On Tue, Sep 17, 2019 at 07:26:58PM +0200, Andrew Lunn wrote:
> > diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> > index b3893347804d..85cf4a4a5e81 100644
> > --- a/drivers/net/phy/at803x.c
> > +++ b/drivers/net/phy/at803x.c
>
> Hi Russell
>
> This won't work. In the kernel logs, you see
>
> kernel: Generic PHY 2188000.ethernet-1:00: attached PHY driver [Generic PHY]
>
> The generic PHY driver is being used, not the at803x driver.
Well, the _correct_ driver needs to be used for the PHY specific
features to be properly controlled. Using the generic driver
in this situation will not be guaranteed to work.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Tue, Sep 17, 2019 at 06:37:28PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 07:26:58PM +0200, Andrew Lunn wrote:
> > > diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> > > index b3893347804d..85cf4a4a5e81 100644
> > > --- a/drivers/net/phy/at803x.c
> > > +++ b/drivers/net/phy/at803x.c
> >
> > Hi Russell
> >
> > This won't work. In the kernel logs, you see
> >
> > kernel: Generic PHY 2188000.ethernet-1:00: attached PHY driver [Generic PHY]
> >
> > The generic PHY driver is being used, not the at803x driver.
>
> Well, the _correct_ driver needs to be used for the PHY specific
> features to be properly controlled. Using the generic driver
> in this situation will not be guaranteed to work.
Well, this hasn't worked, but not for the obvious reason. Register 0x14
is documented as read/write. Bits 15:6 are reserved, bit 5 is the
smart speed enable, 4:2 configures the attempts, bit 1 sets the link
stable condition, bit 0 is reserved.
Writing 0x80c results in the register reading back 0x82c. Writing
0x800 results in the same. Writing 0 reads back 0x2c. Writing 0xffff
seems to prevent packets being passed - and at that point I lost
control so I couldn't see what the result was.
There is nothing in the data sheet which suggests that there is any
gating of this register. So it looks like we're stuck with smartspeed
enabled.
So, I think there's only two remaining ways forward - to revert commit
5502b218e001 to restore the old behaviour, read back the advertisement
from the PHY along with the rest of the status, as I've previously
stated. It means that phylib will modify phydev->advertising at
random points, just as it modifies phydev->lp_advertising, so locking
may become an issue. The revert approach is probably best until we
have something working along those lines.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
> > Well, the _correct_ driver needs to be used for the PHY specific
> > features to be properly controlled. Using the generic driver
> > in this situation will not be guaranteed to work.
I fully agree about the PHY driver. I'm expect this device is
violating c22 when it modifies the advertisement register itself. So
all bets are off for the genphy.
> Well, this hasn't worked, but not for the obvious reason. Register 0x14
> is documented as read/write. Bits 15:6 are reserved, bit 5 is the
> smart speed enable, 4:2 configures the attempts, bit 1 sets the link
> stable condition, bit 0 is reserved.
>
> Writing 0x80c results in the register reading back 0x82c. Writing
> 0x800 results in the same. Writing 0 reads back 0x2c. Writing 0xffff
> seems to prevent packets being passed - and at that point I lost
> control so I couldn't see what the result was.
>
> There is nothing in the data sheet which suggests that there is any
> gating of this register. So it looks like we're stuck with smartspeed
> enabled.
>
> So, I think there's only two remaining ways forward - to revert commit
> 5502b218e001 to restore the old behaviour, read back the advertisement
> from the PHY along with the rest of the status, as I've previously
> stated. It means that phylib will modify phydev->advertising at
> random points, just as it modifies phydev->lp_advertising, so locking
> may become an issue. The revert approach is probably best until we
> have something working along those lines.
We have a couple of other PHYs which support downshift. We should see
if we can follow what they do. What is i think important is that
read_status return the correct speed. So we probably cannot use
genphy_read_status() as is. Maybe we should split genphy_read_status()
into two, so the register reading bit can be done unconditionally by
phy drivers for hardware which don't report link down when they
should?
Andrew
On Tue, Sep 17, 2019 at 07:34:27PM +0300, tinywrkb wrote:
> The patch didn't fix the issue.
>
> # ethtool eth0
>
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Supported pause frame use: Symmetric
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Link partner advertised pause frame use: Symmetric
> Link partner advertised auto-negotiation: Yes
> Link partner advertised FEC modes: Not reported
> Speed: 1000Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 0
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: d
> Wake-on: d
> Link detected: yes
>
> # mii-tool -v -v eth0
>
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 100baseTx-FD flow-control, link ok
> registers for MII PHY 0:
> 3100 796d 004d d072 15e1 c5e1 000f 0000
> 0000 0000 0800 0000 0000 0000 0000 a000
> 0000 0000 0000 f420 082c 0000 04e8 0000
> 3200 3000 0000 063d 0000 0000 0000 0000
> product info: vendor 00:13:74, model 7 rev 2
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
>
> # journalctl -b | egrep -i 'phy|eth|fec'|grep -v usb
>
> kernel: Booting Linux on physical CPU 0x0
> kernel: libphy: Fixed MDIO Bus: probed
> kernel: libphy: fec_enet_mii_bus: probed
> kernel: fec 2188000.ethernet eth0: registered PHC device 0
> kernel: dwhdmi-imx 120000.hdmi: Detected HDMI TX controller v1.31a with HDCP (DWC HDMI 3D TX PHY)
> kernel: Generic PHY 2188000.ethernet-1:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
> kernel: fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> systemd-networkd[242]: eth0: Gained carrier
Okay, so this is getting weird.
ethtool still shows that 1000baseT/Full is being advertised, yet the
PHY disagrees:
3100 796d 004d d072 15e1 c5e1 000f 0000
0000 0000 0800 0000 0000 0000 0000 a000
^^^^
Gigabit control register, bits 9 should be set, but it's clear.
Looking at the following registers, brings up another possibility what
is going on:
0000 0000 0000 f420 082c 0000 04e8 0000
^^^^ ^^^^
These two registers may provide a hint. Of the first register, which
is the interrupt status register, bit 5 is set, indicating that a
"smartspeed downgrade occurred". The second register is the smartspeed
configuration, which basically says that the feature is enabled.
Smartspeed is designed to allow the link to come up if two-pair CAT5
cable is used (are you using a 4-pair or 2-pair cable?) by making the
link fall back to 100mbit, or with CAT3 cable, 10mbit speeds. What
isn't specified is whether it does this by clearing bits in the various
advertisement registers.
Given what you've said so far, I'd suggest that this is indeed the
case - when smartspeed is triggered, advertisement bits are cleared by
the PHY without the kernel's knowledge, leading to the kernel getting
the speed resolution incorrect after 5502b218e001.
There's another issue here - if smartspeed clears advertisement bits,
then if you connect a 4-pair cable after having used a 2-pair cable,
you'd still be limited to 100mbit. The ethtool output will be just
as confusing.
The only thing I can think we should do is to read-back the
advertisement from the PHY whenever we read the rest of the status
and update the phy->advertising mask, just like we do with the link
partner advertisement.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Tue, Sep 17, 2019 at 06:19:13PM +0100, Russell King - ARM Linux admin wrote:
> whether you can get the link to come up at all. You might need to see
> whether wiggling the RJ45 helps (I've had that sort of thing with some
> cables.)
>
> You might also need "ethtool -s eth0 advertise ffcf" after trying that
> if it doesn't work to take the gigabit speeds out of the advertisement.
>
> Thanks.
>
> drivers/net/phy/at803x.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index b3893347804d..85cf4a4a5e81 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
> @@ -296,6 +296,11 @@ static int at803x_config_init(struct phy_device *phydev)
> if (ret < 0)
> return ret;
>
> + /* Disable smartspeed */
> + ret = phy_modify(phydev, 0x14, BIT(5), 0);
> + if (ret < 0)
> + return ret;
> +
> /* The RX and TX delay default is:
> * after HW reset: RX delay enabled and TX delay disabled
> * after SW reset: RX delay enabled, while TX delay retains the
Hi,
Could you try this patch instead - it seems that the PHY needs to be
soft-reset for the write to take effect, and _even_ for the clearance
of the bit to become visible in the register.
I'm not expecting this on its own to solve anything, but it should at
least mean that the at803x doesn't modify the advertisement registers
itself. It may mean that the link doesn't even come up without forcing
the advertisement via the ethtool command I mentioned before.
Thanks.
drivers/net/phy/at803x.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index b3893347804d..69a58c0e6b42 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -296,6 +296,16 @@ static int at803x_config_init(struct phy_device *phydev)
if (ret < 0)
return ret;
+ /* Disable smartspeed */
+ ret = phy_modify(phydev, 0x14, BIT(5), 0);
+ if (ret < 0)
+ return ret;
+
+ /* Must soft-reset the PHY for smartspeed disable to take effect */
+ ret = genphy_soft_reset(phydev);
+ if (ret < 0)
+ return ret;
+
/* The RX and TX delay default is:
* after HW reset: RX delay enabled and TX delay disabled
* after SW reset: RX delay enabled, while TX delay retains the
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> Here's the output of # mii-tool -v -v eth0
>
> * linux-test-5.1rc1-a2703de70942-without_bad_commit
>
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 100baseTx-FD flow-control, link ok
> registers for MII PHY 0:
> 3100 796d 004d d072 15e1 c5e1 000f 0000
> 0000 0000 0800 0000 0000 0000 0000 a000
> 0000 0000 0000 f420 082c 0000 04e8 0000
> 3200 3000 0000 063d 0000 0000 0000 0000
I'll also mention some other discrepencies that I've just spotted in
this register set.
The BMSR is 0x796d. Bit 2 is the link status, which is indicating
that link is up. Bit 5 indicates negotiation complete, which it
claims it is.
The PHY has a second status register at 0x11 which gives real time
information. That is 0x0000. Bit 10 indicates link up, and is
indicating that the link is down. Bit 11 is saying that the speed
and duplex is not resolved either.
So, there's contradictory information being reported by this PHY.
This brings up several questions:
1. what is the _true_ state of the link? Is the link up or down?
2. what does the link partner think is the current link state and
results of negotiation?
3. should we be reading the register at 0x11 to determine the
negotiation results and link state (maybe logically anding the
present state with the BMSR link state)?
Compare that to a correctly functioning AR8035 such as I have in my
cubox-i4 connected to a Netgear GS116 switch:
3100 796d 004d d072 15e1 c5e1 000d 2001
0000 0200 3c00 0000 0000 4007 b29a a000
0862 bc1c 0000 0000 082c 0000 07e8 0000
3200 3000 0000 063e 0000 0005 2d47 8100.
BMSR is again 0x796d. The PHY specific status register this time
is 0xbc1c, which indicates 1G, full duplex, resolved, link up, no
smartspeed downgrade, tx/rx pause.
The register at 0x10 is a control register, which is strangely also
different between our two. Apparently in your PHY configuration,
auto-MDI crossover mode is disabled, you are forced to MDI mode.
On hardware reset, this register contains 0x0862, as per my
example above, but yours is zero.
I don't think the difference in register 0x10 can be explained away
by operation of the smartspeed feature - so maybe my theory about
the advertisement registers being cleared by the PHY is wrong. The
question is: how is 0x10 getting reset to zero in your setup? Maybe
something has corrupted the configuration of the PHY in ways that
Linux doesn't know how to reprogram?
Have you tried power-cycling the cubox-i?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Tue, Sep 17, 2019 at 11:30:13PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> > Here's the output of # mii-tool -v -v eth0
> >
> > * linux-test-5.1rc1-a2703de70942-without_bad_commit
> >
> > Using SIOCGMIIPHY=0x8947
> > eth0: negotiated 100baseTx-FD flow-control, link ok
> > registers for MII PHY 0:
> > 3100 796d 004d d072 15e1 c5e1 000f 0000
> > 0000 0000 0800 0000 0000 0000 0000 a000
> > 0000 0000 0000 f420 082c 0000 04e8 0000
> > 3200 3000 0000 063d 0000 0000 0000 0000
>
> I'll also mention some other discrepencies that I've just spotted in
> this register set.
>
> The BMSR is 0x796d. Bit 2 is the link status, which is indicating
> that link is up. Bit 5 indicates negotiation complete, which it
> claims it is.
>
> The PHY has a second status register at 0x11 which gives real time
> information. That is 0x0000. Bit 10 indicates link up, and is
> indicating that the link is down. Bit 11 is saying that the speed
> and duplex is not resolved either.
>
> So, there's contradictory information being reported by this PHY.
>
> This brings up several questions:
> 1. what is the _true_ state of the link? Is the link up or down?
>
> 2. what does the link partner think is the current link state and
> results of negotiation?
>
> 3. should we be reading the register at 0x11 to determine the
> negotiation results and link state (maybe logically anding the
> present state with the BMSR link state)?
>
>
> Compare that to a correctly functioning AR8035 such as I have in my
> cubox-i4 connected to a Netgear GS116 switch:
>
> 3100 796d 004d d072 15e1 c5e1 000d 2001
> 0000 0200 3c00 0000 0000 4007 b29a a000
> 0862 bc1c 0000 0000 082c 0000 07e8 0000
> 3200 3000 0000 063e 0000 0005 2d47 8100.
>
> BMSR is again 0x796d. The PHY specific status register this time
> is 0xbc1c, which indicates 1G, full duplex, resolved, link up, no
> smartspeed downgrade, tx/rx pause.
>
> The register at 0x10 is a control register, which is strangely also
> different between our two. Apparently in your PHY configuration,
> auto-MDI crossover mode is disabled, you are forced to MDI mode.
> On hardware reset, this register contains 0x0862, as per my
> example above, but yours is zero.
>
> I don't think the difference in register 0x10 can be explained away
> by operation of the smartspeed feature - so maybe my theory about
> the advertisement registers being cleared by the PHY is wrong. The
> question is: how is 0x10 getting reset to zero in your setup? Maybe
> something has corrupted the configuration of the PHY in ways that
> Linux doesn't know how to reprogram?
>
> Have you tried power-cycling the cubox-i?
Hopefully one last thing, which will explain why you may not be able
to get an IP address even with some of these tweaks I've been getting
you to try. Do you have either none or both of these commits in your
kernel?
0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode")
6d4cd041f0af ("net: phy: at803x: disable delay only for RGMII mode")
I think you'll have the latter but not the former. You will need the
former if you have the latter.
I think this thread is a good illustration why breaking existing DT
compatibility - even for the sake of fixing a bug - is just bad news.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Tue, Sep 17, 2019 at 04:17:07PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 02:39:43PM +0100, Russell King - ARM Linux admin wrote:
> > On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> > > On Tue, Sep 17, 2019 at 02:54:34PM +0200, Andrew Lunn wrote:
> > > > On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> > > > > On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > > > > > Tinywrkb confirmed to me in private communication that revert of
> > > > > > > 5502b218e001 fixes Ethernet for him on effected system.
> > > > > > >
> > > > > > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > > > > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > > > > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > > > > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > > > > > AR8035 PHY that supports 1Gb.
> > > > > > >
> > > > > > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > > > > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > > > > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > > > > > the moment.
> > > > > >
> > > > > > Could somebody with an affected device show us the output of ethtool
> > > > > > with and without 5502b218e001. Does one show 1G has been negotiated,
> > > > > > and the other 100Mbps? If this is true, how does it get 100Mbps
> > > > > > without that patch? We are missing a piece of the puzzle.
> > > > > >
> > > > > > Andrew
> > > > >
> > > > > linux-test-5.1rc1-a2703de70942-without_bad_commit
> > > > >
> > > > > Settings for eth0:
> > > > > Supported ports: [ TP MII ]
> > > > > Supported link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > >
> > > > So this means the local device says it can do 1000Mbps.
> > > >
> > > >
> > > > > Supported pause frame use: Symmetric
> > > > > Supports auto-negotiation: Yes
> > > > > Supported FEC modes: Not reported
> > > > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > >
> > > > The link peer can also do 1000Mbps.
> > > >
> > > >
> > > > > Advertised pause frame use: Symmetric
> > > > > Advertised auto-negotiation: Yes
> > > > > Advertised FEC modes: Not reported
> > > > > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Link partner advertised pause frame use: Symmetric
> > > > > Link partner advertised auto-negotiation: Yes
> > > > > Link partner advertised FEC modes: Not reported
> > > > > Speed: 100Mb/s
> > > >
> > > > Yet they have decided to do 100Mbps.
> > > >
> > > > We need to understand Why? The generic PHY driver would not do this on
> > > > its own. So i'm thinking something has poked a PHY register with some
> > > > value, and this patch is causing it to be over written.
> > > >
> > > > Please can you use mii-tool -v -v to dump the PHY registers in each
> > > > case.
> > > >
> > > > Thanks
> > > > Andrew
> > >
> > > Here's the output of # mii-tool -v -v eth0
> > >
> > > * linux-test-5.1rc1-a2703de70942-without_bad_commit
> > >
> > > Using SIOCGMIIPHY=0x8947
> > > eth0: negotiated 100baseTx-FD flow-control, link ok
> > > registers for MII PHY 0:
> > > 3100 796d 004d d072 15e1 c5e1 000f 0000
> > > 0000 0000 0800 0000 0000 0000 0000 a000
> > > 0000 0000 0000 f420 082c 0000 04e8 0000
> > > 3200 3000 0000 063d 0000 0000 0000 0000
> > > product info: vendor 00:13:74, model 7 rev 2
> > > basic mode: autonegotiation enabled
> > > basic status: autonegotiation complete, link ok
> > > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> >
> > This is *not* advertising 1000baseT modes (register 9).
> >
> > >
> > >
> > > * linux-test-5.1rc1-5502b218e001-with_bad_commit
> > >
> > > Using SIOCGMIIPHY=0x8947
> > > eth0: negotiated 100baseTx-FD flow-control, link ok
> > > registers for MII PHY 0:
> > > 3100 796d 004d d072 15e1 c5e1 000d 0000
> > > 0000 0000 0800 0000 0000 0000 0000 a000
> > > 0000 0000 0000 0000 082c 0000 04e8 0000
> > > 3200 3000 0000 063d 0000 0000 0000 0000
> > > product info: vendor 00:13:74, model 7 rev 2
> > > basic mode: autonegotiation enabled
> > > basic status: autonegotiation complete, link ok
> > > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> >
> > Neither is this.
> >
> > However, the kernel and phylib _thinks_ that it is. My guess is
> > something has rewritten the PHY registers from userspace, rather
> > than using ethtool to change the advertisment. The MAC is still
> > trying to operate at 1000Mbps (since that is what phylib resolved)
> > yet the link might be actually operating at 100Mbps - but for that
> > to happen, we should've seen the link go down and up again.
> >
> > Odd.
>
> For reference, here I see:
>
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 1000baseT-FD flow-control, link ok
> registers for MII PHY 0:
> 3100 796d 004d d072 15e1 c1e1 000d 0000
> 0000 0200 3800 0000 0000 0000 0000 a000
> 0000 0000 0000 0000 082c 0000 04e8 0000
> 3200 3000 0000 060e 0000 0000 0000 0000
> product info: vendor 00:13:74, model 7 rev 2
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>
> Note that userspace writing to register 9 (1G settings) will update
> the physical PHY's advertisment for 1G speeds, but the kernel's idea
> will not be updated, so things will become de-sync'd, and the kernel
> _will_ incorrectly determine the speed.
>
> So, are you using mii-tool or mii-diag to change the negotiation
> settings, rather than using ethtool?
>
> This is likely the case, as prior to 5502b218e001, we used to read
> the advertisment registers afresh each time we evaluate the resulting
> link mode. After 5502b218e001, we use the advertisment mask cached
> in phydev->advertising, which, looking at phy_mii_ioctl(), will not
> be updated if register 9 is written.
Please try this patch - I haven't written a commit message for it yet,
it's just to prove the above point.
Thanks.
drivers/net/phy/phy.c | 5 +++++
include/linux/mii.h | 9 +++++++++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 7af390d8bbdb..068a08a50064 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -458,6 +458,11 @@ int phy_mii_ioctl(struct phy_device *phydev, struct ifreq *ifr, int cmd)
val);
change_autoneg = true;
break;
+ case MII_CTRL1000:
+ mii_ctrl1000_mod_linkmode_adv_t(phydev->advertising,
+ val);
+ change_autoneg = true;
+ break;
default:
/* do nothing */
break;
diff --git a/include/linux/mii.h b/include/linux/mii.h
index 5cd824c1c0ca..1249d32dbd63 100644
--- a/include/linux/mii.h
+++ b/include/linux/mii.h
@@ -455,6 +455,15 @@ static inline void mii_lpa_mod_linkmode_lpa_t(unsigned long *lp_advertising,
lp_advertising, lpa & LPA_LPACK);
}
+static inline void mii_ctrl1000_mod_linkmode_adv_t(unsigned long *advertising,
+ u32 ctrl1000)
+{
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT, advertising,
+ ctrl1000 & ADVERTISE_1000HALF);
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT, advertising,
+ ctrl1000 & ADVERTISE_1000FULL);
+}
+
/**
* linkmode_adv_to_lcl_adv_t
* @advertising:pointer to linkmode advertising
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Tue, Sep 17, 2019 at 02:39:43PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> > On Tue, Sep 17, 2019 at 02:54:34PM +0200, Andrew Lunn wrote:
> > > On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> > > > On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > > > > Tinywrkb confirmed to me in private communication that revert of
> > > > > > 5502b218e001 fixes Ethernet for him on effected system.
> > > > > >
> > > > > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > > > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > > > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > > > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > > > > AR8035 PHY that supports 1Gb.
> > > > > >
> > > > > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > > > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > > > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > > > > the moment.
> > > > >
> > > > > Could somebody with an affected device show us the output of ethtool
> > > > > with and without 5502b218e001. Does one show 1G has been negotiated,
> > > > > and the other 100Mbps? If this is true, how does it get 100Mbps
> > > > > without that patch? We are missing a piece of the puzzle.
> > > > >
> > > > > Andrew
> > > >
> > > > linux-test-5.1rc1-a2703de70942-without_bad_commit
> > > >
> > > > Settings for eth0:
> > > > Supported ports: [ TP MII ]
> > > > Supported link modes: 10baseT/Half 10baseT/Full
> > > > 100baseT/Half 100baseT/Full
> > > > 1000baseT/Full
> > >
> > > So this means the local device says it can do 1000Mbps.
> > >
> > >
> > > > Supported pause frame use: Symmetric
> > > > Supports auto-negotiation: Yes
> > > > Supported FEC modes: Not reported
> > > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > > 100baseT/Half 100baseT/Full
> > > > 1000baseT/Full
> > >
> > > The link peer can also do 1000Mbps.
> > >
> > >
> > > > Advertised pause frame use: Symmetric
> > > > Advertised auto-negotiation: Yes
> > > > Advertised FEC modes: Not reported
> > > > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > > > 100baseT/Half 100baseT/Full
> > > > 1000baseT/Full
> > > > Link partner advertised pause frame use: Symmetric
> > > > Link partner advertised auto-negotiation: Yes
> > > > Link partner advertised FEC modes: Not reported
> > > > Speed: 100Mb/s
> > >
> > > Yet they have decided to do 100Mbps.
> > >
> > > We need to understand Why? The generic PHY driver would not do this on
> > > its own. So i'm thinking something has poked a PHY register with some
> > > value, and this patch is causing it to be over written.
> > >
> > > Please can you use mii-tool -v -v to dump the PHY registers in each
> > > case.
> > >
> > > Thanks
> > > Andrew
> >
> > Here's the output of # mii-tool -v -v eth0
> >
> > * linux-test-5.1rc1-a2703de70942-without_bad_commit
> >
> > Using SIOCGMIIPHY=0x8947
> > eth0: negotiated 100baseTx-FD flow-control, link ok
> > registers for MII PHY 0:
> > 3100 796d 004d d072 15e1 c5e1 000f 0000
> > 0000 0000 0800 0000 0000 0000 0000 a000
> > 0000 0000 0000 f420 082c 0000 04e8 0000
> > 3200 3000 0000 063d 0000 0000 0000 0000
> > product info: vendor 00:13:74, model 7 rev 2
> > basic mode: autonegotiation enabled
> > basic status: autonegotiation complete, link ok
> > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
>
> This is *not* advertising 1000baseT modes (register 9).
>
> >
> >
> > * linux-test-5.1rc1-5502b218e001-with_bad_commit
> >
> > Using SIOCGMIIPHY=0x8947
> > eth0: negotiated 100baseTx-FD flow-control, link ok
> > registers for MII PHY 0:
> > 3100 796d 004d d072 15e1 c5e1 000d 0000
> > 0000 0000 0800 0000 0000 0000 0000 a000
> > 0000 0000 0000 0000 082c 0000 04e8 0000
> > 3200 3000 0000 063d 0000 0000 0000 0000
> > product info: vendor 00:13:74, model 7 rev 2
> > basic mode: autonegotiation enabled
> > basic status: autonegotiation complete, link ok
> > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
>
> Neither is this.
>
> However, the kernel and phylib _thinks_ that it is. My guess is
> something has rewritten the PHY registers from userspace, rather
> than using ethtool to change the advertisment. The MAC is still
> trying to operate at 1000Mbps (since that is what phylib resolved)
> yet the link might be actually operating at 100Mbps - but for that
> to happen, we should've seen the link go down and up again.
>
> Odd.
For reference, here I see:
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-FD flow-control, link ok
registers for MII PHY 0:
3100 796d 004d d072 15e1 c1e1 000d 0000
0000 0200 3800 0000 0000 0000 0000 a000
0000 0000 0000 0000 082c 0000 04e8 0000
3200 3000 0000 060e 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
Note that userspace writing to register 9 (1G settings) will update
the physical PHY's advertisment for 1G speeds, but the kernel's idea
will not be updated, so things will become de-sync'd, and the kernel
_will_ incorrectly determine the speed.
So, are you using mii-tool or mii-diag to change the negotiation
settings, rather than using ethtool?
This is likely the case, as prior to 5502b218e001, we used to read
the advertisment registers afresh each time we evaluate the resulting
link mode. After 5502b218e001, we use the advertisment mask cached
in phydev->advertising, which, looking at phy_mii_ioctl(), will not
be updated if register 9 is written.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Tue, Sep 17, 2019 at 04:30:27PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 04:17:07PM +0100, Russell King - ARM Linux admin wrote:
> > On Tue, Sep 17, 2019 at 02:39:43PM +0100, Russell King - ARM Linux admin wrote:
> > > On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> > > > On Tue, Sep 17, 2019 at 02:54:34PM +0200, Andrew Lunn wrote:
> > > > > On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> > > > > > On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > > > > > > Tinywrkb confirmed to me in private communication that revert of
> > > > > > > > 5502b218e001 fixes Ethernet for him on effected system.
> > > > > > > >
> > > > > > > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > > > > > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > > > > > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > > > > > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > > > > > > AR8035 PHY that supports 1Gb.
> > > > > > > >
> > > > > > > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > > > > > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > > > > > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > > > > > > the moment.
> > > > > > >
> > > > > > > Could somebody with an affected device show us the output of ethtool
> > > > > > > with and without 5502b218e001. Does one show 1G has been negotiated,
> > > > > > > and the other 100Mbps? If this is true, how does it get 100Mbps
> > > > > > > without that patch? We are missing a piece of the puzzle.
> > > > > > >
> > > > > > > Andrew
> > > > > >
> > > > > > linux-test-5.1rc1-a2703de70942-without_bad_commit
> > > > > >
> > > > > > Settings for eth0:
> > > > > > Supported ports: [ TP MII ]
> > > > > > Supported link modes: 10baseT/Half 10baseT/Full
> > > > > > 100baseT/Half 100baseT/Full
> > > > > > 1000baseT/Full
> > > > >
> > > > > So this means the local device says it can do 1000Mbps.
> > > > >
> > > > >
> > > > > > Supported pause frame use: Symmetric
> > > > > > Supports auto-negotiation: Yes
> > > > > > Supported FEC modes: Not reported
> > > > > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > > > > 100baseT/Half 100baseT/Full
> > > > > > 1000baseT/Full
> > > > >
> > > > > The link peer can also do 1000Mbps.
> > > > >
> > > > >
> > > > > > Advertised pause frame use: Symmetric
> > > > > > Advertised auto-negotiation: Yes
> > > > > > Advertised FEC modes: Not reported
> > > > > > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > > > > > 100baseT/Half 100baseT/Full
> > > > > > 1000baseT/Full
> > > > > > Link partner advertised pause frame use: Symmetric
> > > > > > Link partner advertised auto-negotiation: Yes
> > > > > > Link partner advertised FEC modes: Not reported
> > > > > > Speed: 100Mb/s
> > > > >
> > > > > Yet they have decided to do 100Mbps.
> > > > >
> > > > > We need to understand Why? The generic PHY driver would not do this on
> > > > > its own. So i'm thinking something has poked a PHY register with some
> > > > > value, and this patch is causing it to be over written.
> > > > >
> > > > > Please can you use mii-tool -v -v to dump the PHY registers in each
> > > > > case.
> > > > >
> > > > > Thanks
> > > > > Andrew
> > > >
> > > > Here's the output of # mii-tool -v -v eth0
> > > >
> > > > * linux-test-5.1rc1-a2703de70942-without_bad_commit
> > > >
> > > > Using SIOCGMIIPHY=0x8947
> > > > eth0: negotiated 100baseTx-FD flow-control, link ok
> > > > registers for MII PHY 0:
> > > > 3100 796d 004d d072 15e1 c5e1 000f 0000
> > > > 0000 0000 0800 0000 0000 0000 0000 a000
> > > > 0000 0000 0000 f420 082c 0000 04e8 0000
> > > > 3200 3000 0000 063d 0000 0000 0000 0000
> > > > product info: vendor 00:13:74, model 7 rev 2
> > > > basic mode: autonegotiation enabled
> > > > basic status: autonegotiation complete, link ok
> > > > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > > > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > > > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > >
> > > This is *not* advertising 1000baseT modes (register 9).
> > >
> > > >
> > > >
> > > > * linux-test-5.1rc1-5502b218e001-with_bad_commit
> > > >
> > > > Using SIOCGMIIPHY=0x8947
> > > > eth0: negotiated 100baseTx-FD flow-control, link ok
> > > > registers for MII PHY 0:
> > > > 3100 796d 004d d072 15e1 c5e1 000d 0000
> > > > 0000 0000 0800 0000 0000 0000 0000 a000
> > > > 0000 0000 0000 0000 082c 0000 04e8 0000
> > > > 3200 3000 0000 063d 0000 0000 0000 0000
> > > > product info: vendor 00:13:74, model 7 rev 2
> > > > basic mode: autonegotiation enabled
> > > > basic status: autonegotiation complete, link ok
> > > > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > > > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > > > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > >
> > > Neither is this.
> > >
> > > However, the kernel and phylib _thinks_ that it is. My guess is
> > > something has rewritten the PHY registers from userspace, rather
> > > than using ethtool to change the advertisment. The MAC is still
> > > trying to operate at 1000Mbps (since that is what phylib resolved)
> > > yet the link might be actually operating at 100Mbps - but for that
> > > to happen, we should've seen the link go down and up again.
> > >
> > > Odd.
> >
> > For reference, here I see:
> >
> > Using SIOCGMIIPHY=0x8947
> > eth0: negotiated 1000baseT-FD flow-control, link ok
> > registers for MII PHY 0:
> > 3100 796d 004d d072 15e1 c1e1 000d 0000
> > 0000 0200 3800 0000 0000 0000 0000 a000
> > 0000 0000 0000 0000 082c 0000 04e8 0000
> > 3200 3000 0000 060e 0000 0000 0000 0000
> > product info: vendor 00:13:74, model 7 rev 2
> > basic mode: autonegotiation enabled
> > basic status: autonegotiation complete, link ok
> > capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> >
> > Note that userspace writing to register 9 (1G settings) will update
> > the physical PHY's advertisment for 1G speeds, but the kernel's idea
> > will not be updated, so things will become de-sync'd, and the kernel
> > _will_ incorrectly determine the speed.
> >
> > So, are you using mii-tool or mii-diag to change the negotiation
> > settings, rather than using ethtool?
> >
> > This is likely the case, as prior to 5502b218e001, we used to read
> > the advertisment registers afresh each time we evaluate the resulting
> > link mode. After 5502b218e001, we use the advertisment mask cached
> > in phydev->advertising, which, looking at phy_mii_ioctl(), will not
> > be updated if register 9 is written.
>
> Please try this patch - I haven't written a commit message for it yet,
> it's just to prove the above point.
>
> Thanks.
>
> drivers/net/phy/phy.c | 5 +++++
> include/linux/mii.h | 9 +++++++++
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 7af390d8bbdb..068a08a50064 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -458,6 +458,11 @@ int phy_mii_ioctl(struct phy_device *phydev, struct ifreq *ifr, int cmd)
> val);
> change_autoneg = true;
> break;
> + case MII_CTRL1000:
> + mii_ctrl1000_mod_linkmode_adv_t(phydev->advertising,
> + val);
> + change_autoneg = true;
> + break;
> default:
> /* do nothing */
> break;
> diff --git a/include/linux/mii.h b/include/linux/mii.h
> index 5cd824c1c0ca..1249d32dbd63 100644
> --- a/include/linux/mii.h
> +++ b/include/linux/mii.h
> @@ -455,6 +455,15 @@ static inline void mii_lpa_mod_linkmode_lpa_t(unsigned long *lp_advertising,
> lp_advertising, lpa & LPA_LPACK);
> }
>
> +static inline void mii_ctrl1000_mod_linkmode_adv_t(unsigned long *advertising,
> + u32 ctrl1000)
> +{
> + linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT, advertising,
> + ctrl1000 & ADVERTISE_1000HALF);
> + linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT, advertising,
> + ctrl1000 & ADVERTISE_1000FULL);
> +}
> +
> /**
> * linkmode_adv_to_lcl_adv_t
> * @advertising:pointer to linkmode advertising
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
The patch didn't fix the issue.
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
# mii-tool -v -v eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD flow-control, link ok
registers for MII PHY 0:
3100 796d 004d d072 15e1 c5e1 000f 0000
0000 0000 0800 0000 0000 0000 0000 a000
0000 0000 0000 f420 082c 0000 04e8 0000
3200 3000 0000 063d 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
# journalctl -b | egrep -i 'phy|eth|fec'|grep -v usb
kernel: Booting Linux on physical CPU 0x0
kernel: libphy: Fixed MDIO Bus: probed
kernel: libphy: fec_enet_mii_bus: probed
kernel: fec 2188000.ethernet eth0: registered PHC device 0
kernel: dwhdmi-imx 120000.hdmi: Detected HDMI TX controller v1.31a with HDCP (DWC HDMI 3D TX PHY)
kernel: Generic PHY 2188000.ethernet-1:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
kernel: fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
systemd-networkd[242]: eth0: Gained carrier
On Tue, Sep 17, 2019 at 11:43:47PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 11:30:13PM +0100, Russell King - ARM Linux admin wrote:
> > On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> > > Here's the output of # mii-tool -v -v eth0
> > >
> > > * linux-test-5.1rc1-a2703de70942-without_bad_commit
> > >
> > > Using SIOCGMIIPHY=0x8947
> > > eth0: negotiated 100baseTx-FD flow-control, link ok
> > > registers for MII PHY 0:
> > > 3100 796d 004d d072 15e1 c5e1 000f 0000
> > > 0000 0000 0800 0000 0000 0000 0000 a000
> > > 0000 0000 0000 f420 082c 0000 04e8 0000
> > > 3200 3000 0000 063d 0000 0000 0000 0000
> >
> > I'll also mention some other discrepencies that I've just spotted in
> > this register set.
> >
> > The BMSR is 0x796d. Bit 2 is the link status, which is indicating
> > that link is up. Bit 5 indicates negotiation complete, which it
> > claims it is.
> >
> > The PHY has a second status register at 0x11 which gives real time
> > information. That is 0x0000. Bit 10 indicates link up, and is
> > indicating that the link is down. Bit 11 is saying that the speed
> > and duplex is not resolved either.
> >
> > So, there's contradictory information being reported by this PHY.
> >
> > This brings up several questions:
> > 1. what is the _true_ state of the link? Is the link up or down?
> >
> > 2. what does the link partner think is the current link state and
> > results of negotiation?
> >
> > 3. should we be reading the register at 0x11 to determine the
> > negotiation results and link state (maybe logically anding the
> > present state with the BMSR link state)?
> >
> >
> > Compare that to a correctly functioning AR8035 such as I have in my
> > cubox-i4 connected to a Netgear GS116 switch:
> >
> > 3100 796d 004d d072 15e1 c5e1 000d 2001
> > 0000 0200 3c00 0000 0000 4007 b29a a000
> > 0862 bc1c 0000 0000 082c 0000 07e8 0000
> > 3200 3000 0000 063e 0000 0005 2d47 8100.
My Cubox-i4 (no issue getting an IP address and GbE) is connected to the
same switch as the Cubox-i2 (the one affected by this bug).
mii-tool output for my Cubox-i4:
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-FD flow-control, link ok
registers for MII PHY 4:
3100 796d 004d d072 15e1 c5e1 000d 0000
0000 0200 3800 0000 0000 0000 0000 a000
0000 0000 0000 0000 082c 0000 04e8 0000
3200 3000 0000 063e 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> >
> > BMSR is again 0x796d. The PHY specific status register this time
> > is 0xbc1c, which indicates 1G, full duplex, resolved, link up, no
> > smartspeed downgrade, tx/rx pause.
> >
> > The register at 0x10 is a control register, which is strangely also
> > different between our two. Apparently in your PHY configuration,
> > auto-MDI crossover mode is disabled, you are forced to MDI mode.
> > On hardware reset, this register contains 0x0862, as per my
> > example above, but yours is zero.
> >
> > I don't think the difference in register 0x10 can be explained away
> > by operation of the smartspeed feature - so maybe my theory about
> > the advertisement registers being cleared by the PHY is wrong. The
> > question is: how is 0x10 getting reset to zero in your setup? Maybe
> > something has corrupted the configuration of the PHY in ways that
> > Linux doesn't know how to reprogram?
> >
> > Have you tried power-cycling the cubox-i?
Yes, it doesn't help.
>
> Hopefully one last thing, which will explain why you may not be able
> to get an IP address even with some of these tweaks I've been getting
> you to try. Do you have either none or both of these commits in your
> kernel?
>
> 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode")
> 6d4cd041f0af ("net: phy: at803x: disable delay only for RGMII mode")
>
> I think you'll have the latter but not the former. You will need the
> former if you have the latter.
>
I was checked-out at 5502b218e001 ("net: phy: use
phy_resolve_aneg_linkmode in genphy_read_status") so I was missing both.
> Could you try this patch instead - it seems that the PHY needs to be
> soft-reset for the write to take effect, and _even_ for the clearance
> of the bit to become visible in the register.
>
> I'm not expecting this on its own to solve anything, but it should at
> least mean that the at803x doesn't modify the advertisement registers
> itself. It may mean that the link doesn't even come up without forcing
> the advertisement via the ethtool command I mentioned before.
>
> Thanks.
>
> drivers/net/phy/at803x.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index b3893347804d..69a58c0e6b42 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
> @@ -296,6 +296,16 @@ static int at803x_config_init(struct phy_device *phydev)
> if (ret < 0)
> return ret;
>
> + /* Disable smartspeed */
> + ret = phy_modify(phydev, 0x14, BIT(5), 0);
> + if (ret < 0)
> + return ret;
> +
> + /* Must soft-reset the PHY for smartspeed disable to take effect */
> + ret = genphy_soft_reset(phydev);
With the smartspeed disabled + soft reset patch against v5.1-rc1 +
cherry-pick the missing 0672d22a1924 ("ARM: dts: imx: Fix the AR803X
phy-mode") I'm finally getting an IP address.
Note that I do need the genphy soft reset without it I don't get an IP
address.
Also tested v5.3 with the patch and it does work.
I'm adding the output for v5.3 with this patch.
# mii-tool -v -v eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD flow-control, link ok
registers for MII PHY 0:
3100 796d 004d d072 15e1 45e1 0007 0000
0000 0200 0000 0000 0000 0000 0000 a000
0000 0000 0000 f400 080c 0000 04e8 0000
3200 3000 0000 063d 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
# journalctl -b | egrep -i 'phy|eth|fec'|grep -v usb
kernel: Booting Linux on physical CPU 0x0
kernel: libphy: Fixed MDIO Bus: probed
kernel: libphy: fec_enet_mii_bus: probed
kernel: fec 2188000.ethernet eth0: registered PHC device 0
kernel: Atheros 8035 ethernet 2188000.ethernet-1:00: attached PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
kernel: Atheros 8035 ethernet 2188000.ethernet-1:00: PHY advertising (00,00000200,000022ef) more modes than genphy supports, some modes not advertised.
kernel: fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
systemd-networkd[364]: eth0: Gained carrier
systemd-networkd[364]: eth0: DHCPv4 address 192.168.15.101/24 via 192.168.15.1
systemd-networkd[364]: eth0: Gained IPv6LL
systemd-networkd[364]: eth0: Configured
> I think this thread is a good illustration why breaking existing DT
> compatibility - even for the sake of fixing a bug - is just bad news.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
On Tue, Sep 17, 2019 at 10:42:01PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 06:19:13PM +0100, Russell King - ARM Linux admin wrote:
> > whether you can get the link to come up at all. You might need to see
> > whether wiggling the RJ45 helps (I've had that sort of thing with some
> > cables.)
> >
> > You might also need "ethtool -s eth0 advertise ffcf" after trying that
> > if it doesn't work to take the gigabit speeds out of the advertisement.
> >
> > Thanks.
> >
> > drivers/net/phy/at803x.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> > index b3893347804d..85cf4a4a5e81 100644
> > --- a/drivers/net/phy/at803x.c
> > +++ b/drivers/net/phy/at803x.c
> > @@ -296,6 +296,11 @@ static int at803x_config_init(struct phy_device *phydev)
> > if (ret < 0)
> > return ret;
> >
> > + /* Disable smartspeed */
> > + ret = phy_modify(phydev, 0x14, BIT(5), 0);
> > + if (ret < 0)
> > + return ret;
> > +
> > /* The RX and TX delay default is:
> > * after HW reset: RX delay enabled and TX delay disabled
> > * after SW reset: RX delay enabled, while TX delay retains the
>
> Hi,
>
> Could you try this patch instead - it seems that the PHY needs to be
> soft-reset for the write to take effect, and _even_ for the clearance
> of the bit to become visible in the register.
>
> I'm not expecting this on its own to solve anything, but it should at
> least mean that the at803x doesn't modify the advertisement registers
> itself. It may mean that the link doesn't even come up without forcing
> the advertisement via the ethtool command I mentioned before.
>
> Thanks.
>
> drivers/net/phy/at803x.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index b3893347804d..69a58c0e6b42 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
> @@ -296,6 +296,16 @@ static int at803x_config_init(struct phy_device *phydev)
> if (ret < 0)
> return ret;
>
> + /* Disable smartspeed */
> + ret = phy_modify(phydev, 0x14, BIT(5), 0);
> + if (ret < 0)
> + return ret;
> +
> + /* Must soft-reset the PHY for smartspeed disable to take effect */
> + ret = genphy_soft_reset(phydev);
> + if (ret < 0)
> + return ret;
> +
> /* The RX and TX delay default is:
> * after HW reset: RX delay enabled and TX delay disabled
> * after SW reset: RX delay enabled, while TX delay retains the
Bad news I'm afraid. It looks like the AR8035 has a bug in it.
Disabling the SmartSpeed feature appears to make register 9, the
1000BASET control register, read-only.
For example:
Reading 0x0009=0x0200
Writing 0x0014=0x082c <= smartspeed enabled
Writing 0x0000=0xb100 <= soft reset
Writing 0x0009=0x0600
Reading 0x0009=0x0600 <= it took the value
Reading 0x0009=0x0600
Writing 0x0014=0x080c <= smartspeed disabled
Writing 0x0000=0xb100 <= soft reset
Writing 0x0009=0x0200
Reading 0x0009=0x0600 <= it ignored the write
Reading 0x0009=0x0600
Writing 0x0014=0x082c <= smartspeed enabled
Writing 0x0000=0xb100 <= soft reset
Writing 0x0009=0x0200
Reading 0x0009=0x0200 <= it took the value
If it's going to make register 9 read-only when smartspeed is disabled,
then that's another failure mode and autonegotiation cockup just
waiting to happen - which I spotted when trying to configure the
advertisement using ethtool, and finding that it was impossible to stop
1000baseT/Full being advertised.
I think the only sane approach - at least until we have something more
reasonable in place - is to base the negotiation result off what is
actually stored in the PHY registers at the time the link comes up, and
not on the cached versions of what we should be advertising.
5502b218e001 has caused this regression, and where we are now after
more than a week of trying to come up with some fix for this
regression, the only solution that seems to work without introducing
more failures is to revert that commit.
Adding Heiner (original commit author), Florian, David and netdev.
Thoughts?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Tue, Sep 17, 2019 at 08:39:34PM +0200, Andrew Lunn wrote:
> > > Well, the _correct_ driver needs to be used for the PHY specific
> > > features to be properly controlled. Using the generic driver
> > > in this situation will not be guaranteed to work.
>
> I fully agree about the PHY driver. I'm expect this device is
> violating c22 when it modifies the advertisement register itself. So
> all bets are off for the genphy.
>
> > Well, this hasn't worked, but not for the obvious reason. Register 0x14
> > is documented as read/write. Bits 15:6 are reserved, bit 5 is the
> > smart speed enable, 4:2 configures the attempts, bit 1 sets the link
> > stable condition, bit 0 is reserved.
> >
> > Writing 0x80c results in the register reading back 0x82c. Writing
> > 0x800 results in the same. Writing 0 reads back 0x2c. Writing 0xffff
> > seems to prevent packets being passed - and at that point I lost
> > control so I couldn't see what the result was.
> >
> > There is nothing in the data sheet which suggests that there is any
> > gating of this register. So it looks like we're stuck with smartspeed
> > enabled.
> >
> > So, I think there's only two remaining ways forward - to revert commit
> > 5502b218e001 to restore the old behaviour, read back the advertisement
> > from the PHY along with the rest of the status, as I've previously
> > stated. It means that phylib will modify phydev->advertising at
> > random points, just as it modifies phydev->lp_advertising, so locking
> > may become an issue. The revert approach is probably best until we
> > have something working along those lines.
>
> We have a couple of other PHYs which support downshift. We should see
> if we can follow what they do. What is i think important is that
> read_status return the correct speed. So we probably cannot use
> genphy_read_status() as is. Maybe we should split genphy_read_status()
> into two, so the register reading bit can be done unconditionally by
> phy drivers for hardware which don't report link down when they
> should?
I think we need to check how the downshift feature works on other PHYs
and whether it is enabled there.
Looking at the Marvell 88e151x PHYs, they have the feature, but do not
enable it by default. If firmware has enabled the feature, phylib will
incorrectly resolve the link speed based on just the advertisements.
I think the safest way in the case of both PHYs to ascertain the real
link speed is to read the Specific Status register - register 17 in
both cases. The top two bits indicate the negotiated speed resolution
and bit 13 indicates the duplex. Bit 11 indicates whether the
resolution is valid. This register layout seems to apply to both
88e151x and AR8035.
The register also contains the pause mode resolution in terms of
receive or transmit pause enabled, but this is not useful to phylib
as that is not what phylib wants to know. However, it probably makes
sense for phylib to resolve the pause mode negotiation itself rather
than having that logic in the MAC drivers.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up