From: Arınç ÜNAL <[email protected]>
There's no need to disable Energy-Efficient Ethernet (EEE) advertisement on
the MT7530 and MT7531 switch PHYs. EEE works fine on MT7530 and MT7531
switch PHYs. Remove the code where EEE advertisement is disabled.
This is a bugfix because there's a possible race condition where the
mediatek-ge driver would kick in after the MT7530 DSA subdriver which would
have EEE disabled until manually enabled.
Fixes: e40d2cca0189 ("net: phy: add MediaTek Gigabit Ethernet PHY driver")
Signed-off-by: Arınç ÜNAL <[email protected]>
---
drivers/net/phy/mediatek-ge.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/phy/mediatek-ge.c b/drivers/net/phy/mediatek-ge.c
index a493ae01b267..54ea64a37ab3 100644
--- a/drivers/net/phy/mediatek-ge.c
+++ b/drivers/net/phy/mediatek-ge.c
@@ -23,9 +23,6 @@ static int mtk_gephy_write_page(struct phy_device *phydev, int page)
static void mtk_gephy_config_init(struct phy_device *phydev)
{
- /* Disable EEE */
- phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
-
/* Enable HW auto downshift */
phy_modify_paged(phydev, MTK_PHY_PAGE_EXTENDED, 0x14, 0, BIT(4));
--
2.40.1
On 3/18/2024 12:46 AM, Arınç ÜNAL via B4 Relay wrote:
> From: Arınç ÜNAL <[email protected]>
>
> There's no need to disable Energy-Efficient Ethernet (EEE) advertisement on
> the MT7530 and MT7531 switch PHYs. EEE works fine on MT7530 and MT7531
> switch PHYs. Remove the code where EEE advertisement is disabled.
>
> This is a bugfix because there's a possible race condition where the
> mediatek-ge driver would kick in after the MT7530 DSA subdriver which would
> have EEE disabled until manually enabled.
>
> Fixes: e40d2cca0189 ("net: phy: add MediaTek Gigabit Ethernet PHY driver")
> Signed-off-by: Arınç ÜNAL <[email protected]>
Could we get Sean to chime in, maybe there was a valid reason to disable
EEE advertisement in the first place?
--
Florian
On 18.03.2024 10:46, Arınç ÜNAL via B4 Relay wrote:
> From: Arınç ÜNAL <[email protected]>
>
> There's no need to disable Energy-Efficient Ethernet (EEE) advertisement on
> the MT7530 and MT7531 switch PHYs. EEE works fine on MT7530 and MT7531
> switch PHYs. Remove the code where EEE advertisement is disabled.
>
> This is a bugfix because there's a possible race condition where the
> mediatek-ge driver would kick in after the MT7530 DSA subdriver which would
> have EEE disabled until manually enabled.
Can I get an opinion on this? Is it actually possible that the PHY driver
would start probing after the DSA subdriver? On the console logs for the
DSA subdriver, I can see that the name of the PHY driver will appear, which
makes me believe the PHY driver would actually never probe after the DSA
subdriver.
[ 4.402641] mt7530-mdio mdio-bus:1f wan (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7530 PHY] (irq=POLL)
[ 4.420392] mt7530-mdio mdio-bus:1f lan0 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=POLL)
[ 4.437791] mt7530-mdio mdio-bus:1f lan1 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=POLL)
[ 4.455096] mt7530-mdio mdio-bus:1f lan2 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=POLL)
[ 4.472422] mt7530-mdio mdio-bus:1f lan3 (uninitialized): PHY [mt7530-0:04] driver [MediaTek MT7530 PHY] (irq=POLL)
I don't want to submit a bugfix to the net tree if the bug won't ever
happen in real life.
Arınç
On Wed, Mar 20, 2024 at 11:40:56PM +0300, Arınç ÜNAL wrote:
> On 18.03.2024 10:46, Arınç ÜNAL via B4 Relay wrote:
> > From: Arınç ÜNAL <[email protected]>
> >
> > There's no need to disable Energy-Efficient Ethernet (EEE) advertisement on
> > the MT7530 and MT7531 switch PHYs. EEE works fine on MT7530 and MT7531
> > switch PHYs. Remove the code where EEE advertisement is disabled.
> >
> > This is a bugfix because there's a possible race condition where the
> > mediatek-ge driver would kick in after the MT7530 DSA subdriver which would
> > have EEE disabled until manually enabled.
>
> Can I get an opinion on this? Is it actually possible that the PHY driver
> would start probing after the DSA subdriver? On the console logs for the
> DSA subdriver, I can see that the name of the PHY driver will appear, which
> makes me believe the PHY driver would actually never probe after the DSA
> subdriver.
>
> [ 4.402641] mt7530-mdio mdio-bus:1f wan (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7530 PHY] (irq=POLL)
> [ 4.420392] mt7530-mdio mdio-bus:1f lan0 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=POLL)
> [ 4.437791] mt7530-mdio mdio-bus:1f lan1 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=POLL)
> [ 4.455096] mt7530-mdio mdio-bus:1f lan2 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=POLL)
> [ 4.472422] mt7530-mdio mdio-bus:1f lan3 (uninitialized): PHY [mt7530-0:04] driver [MediaTek MT7530 PHY] (irq=POLL)
>
> I don't want to submit a bugfix to the net tree if the bug won't ever
> happen in real life.
It would be really great if you could tell us which bug fixes you're
submitting are for a real problem that you or a user have encountered,
and which are down to essentially code inspection and things that
"aren't correct". Basically, don't do this.
It isn't true that the PHY specific driver will be probed before DSA
initialises - consider the case where the DSA driver is built-in but
the PHY specific driver is modular and on the not-yet-mounted rootfs.
That would result in the generic PHY driver being used even when the
PHY specific driver were to be loaded later - and thus only basic
standard 802.3 PHY behaviour will be supported.
That's not specific to mt7530, it applies to everything that uses
phylib. It isn't something that really warrants "bug fixing" in each
and every driver.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On 20.03.2024 23:53, Russell King (Oracle) wrote:
> On Wed, Mar 20, 2024 at 11:40:56PM +0300, Arınç ÜNAL wrote:
>> On 18.03.2024 10:46, Arınç ÜNAL via B4 Relay wrote:
>> Can I get an opinion on this? Is it actually possible that the PHY driver
>> would start probing after the DSA subdriver? On the console logs for the
>> DSA subdriver, I can see that the name of the PHY driver will appear, which
>> makes me believe the PHY driver would actually never probe after the DSA
>> subdriver.
>>
>> [ 4.402641] mt7530-mdio mdio-bus:1f wan (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7530 PHY] (irq=POLL)
>> [ 4.420392] mt7530-mdio mdio-bus:1f lan0 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=POLL)
>> [ 4.437791] mt7530-mdio mdio-bus:1f lan1 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=POLL)
>> [ 4.455096] mt7530-mdio mdio-bus:1f lan2 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=POLL)
>> [ 4.472422] mt7530-mdio mdio-bus:1f lan3 (uninitialized): PHY [mt7530-0:04] driver [MediaTek MT7530 PHY] (irq=POLL)
>>
>> I don't want to submit a bugfix to the net tree if the bug won't ever
>> happen in real life.
>
> It would be really great if you could tell us which bug fixes you're
> submitting are for a real problem that you or a user have encountered,
> and which are down to essentially code inspection and things that
> "aren't correct". Basically, don't do this.
I agree. Patch 1 fixes a real problem, patch 2 "fixes" a problem found with
code inspection. Though, it would be great if you could review patch 2.
>
> It isn't true that the PHY specific driver will be probed before DSA
> initialises - consider the case where the DSA driver is built-in but
> the PHY specific driver is modular and on the not-yet-mounted rootfs.
> That would result in the generic PHY driver being used even when the
> PHY specific driver were to be loaded later - and thus only basic
> standard 802.3 PHY behaviour will be supported.
>
> That's not specific to mt7530, it applies to everything that uses
> phylib. It isn't something that really warrants "bug fixing" in each
> and every driver.
That makes sense. But there's a special case with the MT7530 DSA subdriver
and mediatek-ge driver. The PHY driver is needed for the PHYs to function
properly. So the DSA subdriver forces mediatek-ge to be selected [1]. So
the PHY driver could only be compiled as a module when the DSA subdriver is
also compiled so. And that designates mediatek-ge as a dependency for the
DSA subdriver, if I understand correctly.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=fb4bb62aaac715e50c7c007714af19a2698db88b