Re: [PATCH net v3] net: phy: mediatek-ge: disable EEE on the MT7530 PHY

["Bjørn Mork" <bjorn@mork.no>]

Vladislav Karmanov <vladislav.karmanov.dev@gmail.com> writes:

> The MT7530 internal GE PHY advertises EEE by hardware default, but its
> EEE support is defective: with EEE advertised, some link partners fail
> to establish a stable link. On a 2-pair (4-wire) cable where both ends
> advertise gigabit, 1000BASE-T training cannot succeed, and instead of
> falling back to 100 Mbps the port loops, so no link or DHCP lease is
> ever obtained.

I realize that I'm too late at the party here, but I still want to state
this for the record:

I just tried to reproduce this bug on a Zyxel NR7101, using a cable with
pair 4 cut, connecting to the I219-LM controller in my laptop.  Without
success.

EEE enabled or not does not make any difference.  The link is negotiated
as 100Mb/s as expected, and it is completely stable.  Absolutely no
issues observed.  I even added a .link_change_notify callback with a
counter and a printk to the phy driver to make sure I didn't miss any
flapping.

MT7621 side:

root@OpenWrt:~# ethtool --show-eee lan
EEE settings for lan:
        EEE status: enabled - active
        Tx LPI: 30 (us)
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
        Link partner advertised EEE link modes:  100baseT/Full
                                                 1000baseT/Full
root@OpenWrt:~# ethtool lan
Settings for lan:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        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 Receive-only
        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: No
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Full
        Auto-negotiation: on
        master-slave cfg: preferred master
        master-slave status: master
        Port: Twisted Pair
        PHYAD: 2
        Transceiver: external
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Link detected: yes

I219-LM side:

root@miraculix:/tmp# ethtool --show-eee eth0
EEE settings for eth0:
        EEE status: enabled - active
        Tx LPI: 17 (us)
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
        Link partner advertised EEE link modes:  100baseT/Full
                                                 1000baseT/Full
root@miraculix:/tmp# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        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 Receive-only
        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 Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 2
        Transceiver: internal
        MDI-X: on (auto)
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes


So now I am curious to know:  What am I doing wrong here?

I primarily did this test because I wanted to implement a smarter
workaround, without forcibly disabling EEE for everyone based on one
pretty obscure configuration.  But that's hard without being able to
reproduce the problem.

So let me ask you, who seem to be able to reproduce it:  Why is it
necessary to block EEE for everyone? Why can't you disable EEE by
default, but let me enable it on my systems - where I know it works?

Or even better:  Why can't you detect the link flaps and only disable
EEE when required? (this was my plan)

FWIW, I have been using EEE on MT7621 devices for years without ever
noticing the claimed issue.  I have heard the rumours that the SoC is
supposed to have occasional link issues, and that they are related to
EEE.  But reproducing the issue has so far been impossible.

> MediaTek confirms the hardware is the root cause (Landen
> Chao, 2021): "EEE of the 10-year-old MT7530 internal gephy has many IOT
> problems, so it is recommended to disable its EEE."

This is BS. I don't doubt that there are bugs in the MT7530 gephy. But
the EEE feature of the MT7530 internal gephy works fine for me.  And
always has.

Vendors have no interest in making older hardware work. There is no
reason to ask them or trust them when it comes to hardware they don't
sell anymore.

We can do better. And we have, by for example bringing DSA to the
MT7621. Please, let's try to make even old hardware work as good as
possible.  Disabling features is not the way to go.

> Auto-negotiation then falls back to a stable 100 Mbps link instead of
> looping at gigabit. Tested on ASUS RT-AX53U (MT7621): with a 2-pair
> cable on the WAN port, a single clean 100 Mbps link comes up and a
> DHCP lease is obtained, where the unpatched driver loops.

And no I've tested the same configuration with EEE enabled, and it
doesn't loop either.

Where does that put us?


Bjørn