Chester A. Unal on Mon Apr 14 03:11:14 PDT 2025 wrote:*
*
Hello Felix.
>/sorry to bother you with this again. />/The WAX206 issue with it's Realtek WAN PHY has long been resolved but
the mt7621-ramips plattform is still causing issues for users on the
new release due to unstable/sometimes not working ethernet link. />//>/matjon just put some effort into debugging this (to some degree) />/<https://github.com/openwrt/openwrt/issues/17351#issuecomment-2798953937>
/>//>/And HanabishiRecca noticed that EEE somehow gets enabled even when
the receiving side has it disabled. />/<https://github.com/openwrt/openwrt/issues/17351#issuecomment-2799921359>
/>//>/Do their posts somehow shine a different light on the matter or do
you have an idea what could be at fault? /
No, it doesn't shine a different light.
>/Does EEE itself work fine but gets enabled when it shouldn't be? /
I can't say for certain. I don't think it matters to do so anyway, for the
issue at hand.
>//>/I know you are maintaining only the mt7530 part and not all related
code so I don't expect you to change anything upstream. Though your
opinion on the matter would be very valuable to us here. :) /
My opinion hasn't changed. I still suspect the same thing that I stated on
the GitHub issue [1]:
>/I'm going to refrain from disabling EEE for now as I see reports here /that
suggest that it is not EEE that is the cause of the problem, but
rather it reveals an issue of race condition of sorts when EEE is enabled.
Perhaps the cause is in the MediaTek ethernet driver...
Hello,
I have been working on this issue and trying to debug it.
I have been following this bug report closely and I think that every
credible
report there (that cannot be explained by another cause) has
been on ramips/mt7621.
That report by Florian Maurer [1] on Netgear WAX206 which you quoted
previously turned out to be a different issue and has already been fixed
[2].
There was also a report from @raenye, which turned out to be
caused by a bad cable. @lorand-horvath described a problem on RT-AX59U,
(ARM / mediatek target) with the mt7531 external switch, however the
symptoms were very atypical (several flaps during a minute) and
happened only once.
There has also been a report by barcell1 of apparent hardware damage
just after flashing OpenWRT 24.10, which persisted after reverting to 23.05:
|[ 2.774046] mt7530-mdio mdio-bus:1f: reset timeout [ 2.778946]
mt7530-mdio: probe of mdio-bus:1f failed with error -145|
Get someone from MediaTek involved. I've got nothing else to add.
Back in 2021, Landen Chao from MediaTek described why disabling EEE is
recommended [4]:
W dniu 20.05.2021 o 09:13, Landen Chao pisze:
On Thu, 2021-05-20 at 10:38 +0800, DENG Qingfang wrote:
On Thu, May 20, 2021 at 02:59:21AM +0200, Andrew Lunn wrote:
> +static void mtk_gephy_config_init(struct phy_device *phydev) > +{ > + /* Disable EEE */ > + phy_write_mmd(phydev, MDIO_MMD_AN,
MDIO_AN_EEE_ADV, 0);
Is EEE broken on this PHY? Or is this just to get it into a defined
state?
As I said in commit message, the initialization (including EEE) is
from the vendor driver.
I have also tested it with EEE enabled by default on one of my APs,
and got occasional link drops.
EEE of the 10-year-old MT7530 internal gephy has many IOT problems, so
it is recommended to disable its EEE.
EEE of the MT7531 internal gephy has been updated, but it is not yet
widely used.
Therefore, EEE is disabled in vendor driver.
Landen
Apparently the way EEE has been disabled for mt7530 stopped working
somewhere between Linux 5.15 and 6.6. The present way to disable EEE in
a PHY driver appears appears to be in drivers/net/phy/micrel.c:
> phydev
<https://elixir.bootlin.com/linux/v6.6.83/C/ident/phydev>->eee_broken_modes
<https://elixir.bootlin.com/linux/v6.6.83/C/ident/eee_broken_modes>=-1;
I'm going to reconfirm at Mediatek, but in the end I will probably just
post a patch to mark EEE as broken in the devicetree.
Greetings,
Mateusz
[1] https://github.com/openwrt/openwrt/issues/17351#issuecomment-2608342255
[2] https://github.com/openwrt/openwrt/pull/17701
[3] https://github.com/openwrt/openwrt/issues/17351#issuecomment-2773185300
[4]
https://lore.kernel.org/all/0adde34f936a2dafca40b06b408d82afe0852327.ca...@mediatek.com/
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
