[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00ec9779-19ce-4005-83f0-f4abf37350fc@arinc9.com>
Date: Tue, 19 Mar 2024 21:46:30 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: Daniel Golle <daniel@...rotopia.org>
Cc: DENG Qingfang <dqfext@...il.com>, Sean Wang <sean.wang@...iatek.com>,
Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
René van Dorst <opensource@...rst.com>,
Russell King <linux@...linux.org.uk>,
SkyLake Huang <SkyLake.Huang@...iatek.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Bartel Eerdekens <bartel.eerdekens@...stell8.be>, mithat.guner@...ont.com,
erkin.bozoglu@...ont.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 0/3] Fix EEE support for MT7531 and MT7988 SoC switch
On 19.03.2024 21:25, Daniel Golle wrote:
> On Mon, Mar 18, 2024 at 10:46:22AM +0300, Arınç ÜNAL via B4 Relay wrote:
>> Hi.
>>
>> This patch series fixes EEE support for MT7531 and the switch on the MT7988
>> SoC. EEE did not work on MT7531 on most boards before this, it is unclear
>> what's the status on MT7988 SoC switch as I don't have the hardware.
>
> EEE seems to already work just fine on the MT7988 built-in switch, at least
> on the BPI-R4. I don't think the SoC has bootstrap pins related to EEE like
> stand-alone MT753x may have.
>
> root@...-r4:~# ethtool --show-eee lan1
> EEE settings for lan1:
> EEE status: disabled
> Tx LPI: 30 (us)
> Supported EEE link modes: 100baseT/Full
> 1000baseT/Full
> Advertised EEE link modes: Not reported
> Link partner advertised EEE link modes: 100baseT/Full
> 1000baseT/Full
>
> root@...-r4:~# ethtool --set-eee lan1 eee on
> root@...-r4:~# ethtool --show-eee lan1
> EEE settings for lan1:
> EEE status: enabled - inactive
> 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: Not reported
> root@...-r4:~# ethtool --show-eee lan1
> EEE settings for lan1:
> 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
>
> So don't fix if it ain't broken maybe...?
I would argue that EEE advertisement on the PHY should be enabled by
default. I guess we're supposed to supply that on the PHY driver. Can you
test with this diff applied and see if it works without manually enabling
EEE using ethtool?
diff --git a/drivers/net/phy/mediatek-ge-soc.c b/drivers/net/phy/mediatek-ge-soc.c
index 0f3a1538a8b8..5f482c12018a 100644
--- a/drivers/net/phy/mediatek-ge-soc.c
+++ b/drivers/net/phy/mediatek-ge-soc.c
@@ -978,6 +978,9 @@ static void mt798x_phy_eee(struct phy_device *phydev)
MTK_PHY_RG_LPI_PCS_DSP_CTRL_REG122,
MTK_PHY_LPI_NORM_MSE_HI_THRESH1000_MASK,
FIELD_PREP(MTK_PHY_LPI_NORM_MSE_HI_THRESH1000_MASK, 0xff));
+
+ phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, MDIO_EEE_100TX |
+ MDIO_EEE_1000T);
}
static int cal_sw(struct phy_device *phydev, enum CAL_ITEM cal_item,
Arınç
Powered by blists - more mailing lists