From: Daniel Golle <daniel@makrotopia.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: arinc.unal@arinc9.com, "DENG Qingfang" <dqfext@gmail.com>,
"Sean Wang" <sean.wang@mediatek.com>,
"Andrew Lunn" <andrew@lunn.ch>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Vladimir Oltean" <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"René van Dorst" <opensource@vdorst.com>,
"Russell King" <linux@armlinux.org.uk>,
"SkyLake Huang" <SkyLake.Huang@mediatek.com>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Bartel Eerdekens" <bartel.eerdekens@constell8.be>,
mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
"Florian Fainelli" <florian.fainelli@broadcom.com>
Subject: Re: [PATCH net v3] net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards
Date: Wed, 10 Apr 2024 19:52:24 +0100 [thread overview]
Message-ID: <Zhbf6AtfBfxXMIGc@makrotopia.org> (raw)
In-Reply-To: <1f2bc5416a0a73756cc1f45f3300619eb201b0a4.camel@redhat.com>
On Tue, Apr 09, 2024 at 01:58:56PM +0200, Paolo Abeni wrote:
> On Mon, 2024-04-08 at 10:08 +0300, Arınç ÜNAL via B4 Relay wrote:
> > From: Arınç ÜNAL <arinc.unal@arinc9.com>
> >
> > The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features")
> > brought EEE support but did not enable EEE on MT7531 MACs. EEE is
> > enabled on MT7531 switch MACs by pulling the LAN2LED0 pin low on the board
> > (bootstrapping), unsetting the EEE_DIS bit on the trap register, or setting
> > the internal EEE switch bit on the CORE_PLL_GROUP4 register. Thanks to
> > SkyLake Huang (黃啟澤) from MediaTek for providing information on the
> > internal EEE switch bit.
> >
> > There are existing boards that were not designed to pull the pin low.
> > Because of that, the EEE status currently depends on the board design.
> >
> > The EEE_DIS bit on the trap pertains to the LAN2LED0 pin which is usually
> > used to control an LED. Once the bit is unset, the pin will be low. That
> > will make the active low LED turn on. The pin is controlled by the switch
> > PHY. It seems that the PHY controls the pin in the way that it inverts the
> > pin state. That means depending on the wiring of the LED connected to
> > LAN2LED0 on the board, the LED may be on without an active link.
> >
> > To not cause this unwanted behaviour whilst enabling EEE on all boards, set
> > the internal EEE switch bit on the CORE_PLL_GROUP4 register.
> >
> > My testing on MT7531 shows a certain amount of traffic loss when EEE is
> > enabled. That said, I haven't come across a board that enables EEE. So
> > enable EEE on the switch MACs but disable EEE advertisement on the switch
> > PHYs. This way, we don't change the behaviour of the majority of the boards
> > that have this switch. The mediatek-ge PHY driver already disables EEE
> > advertisement on the switch PHYs but my testing shows that it is somehow
> > enabled afterwards. Disabling EEE advertisement before the PHY driver
> > initialises keeps it off.
> >
> > With this change, EEE can now be enabled using ethtool.
> >
> > Fixes: 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features")
> > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
> > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> > ---
> > Here's some information for the record. EEE could not be enabled on MT7531
> > on most boards using ethtool before this. On MT7988 SoC switch, EEE is
> > disabled by default but can be turned on normally using ethtool. EEE is
> > enabled by default on MT7530 and there's no need to make changes on the DSA
> > subdriver for it.
> > ---
> > Changes in v3:
> > - Remove patch 2, it was revealed that it doesn't fix a bug.
> > - Patch 1
> > - Use the internal EEE switch bit provided by SkyLake Huang (黃啟澤). It
> > is a better method compared to unsetting the EEE_DIS bit of the trap as
> > the latter method causes unwanted behaviour on the LED connected to the
> > pin that pertains to the EEE_DIS bit.
>
> Since this leverages something relatively obscure, it would be great if
> someone in the CC list could independently test it. Let's wait a bit
> more.
I've excessively tested this patch on MT7531 today, and reviewed it
today and yesterday. I've also picked it as downstream patch[1] to
OpenWrt, so an even wider audience will have the pleasure of working
EEE on those switch ICs and in-SoC switches.
Tested-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
[1]: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=98f9154316fe8371c709bd11ae8f263e22075ec6
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Golle <daniel@makrotopia.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: arinc.unal@arinc9.com, "DENG Qingfang" <dqfext@gmail.com>,
"Sean Wang" <sean.wang@mediatek.com>,
"Andrew Lunn" <andrew@lunn.ch>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Vladimir Oltean" <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"René van Dorst" <opensource@vdorst.com>,
"Russell King" <linux@armlinux.org.uk>,
"SkyLake Huang" <SkyLake.Huang@mediatek.com>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Bartel Eerdekens" <bartel.eerdekens@constell8.be>,
mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
"Florian Fainelli" <florian.fainelli@broadcom.com>
Subject: Re: [PATCH net v3] net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards
Date: Wed, 10 Apr 2024 19:52:24 +0100 [thread overview]
Message-ID: <Zhbf6AtfBfxXMIGc@makrotopia.org> (raw)
In-Reply-To: <1f2bc5416a0a73756cc1f45f3300619eb201b0a4.camel@redhat.com>
On Tue, Apr 09, 2024 at 01:58:56PM +0200, Paolo Abeni wrote:
> On Mon, 2024-04-08 at 10:08 +0300, Arınç ÜNAL via B4 Relay wrote:
> > From: Arınç ÜNAL <arinc.unal@arinc9.com>
> >
> > The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features")
> > brought EEE support but did not enable EEE on MT7531 MACs. EEE is
> > enabled on MT7531 switch MACs by pulling the LAN2LED0 pin low on the board
> > (bootstrapping), unsetting the EEE_DIS bit on the trap register, or setting
> > the internal EEE switch bit on the CORE_PLL_GROUP4 register. Thanks to
> > SkyLake Huang (黃啟澤) from MediaTek for providing information on the
> > internal EEE switch bit.
> >
> > There are existing boards that were not designed to pull the pin low.
> > Because of that, the EEE status currently depends on the board design.
> >
> > The EEE_DIS bit on the trap pertains to the LAN2LED0 pin which is usually
> > used to control an LED. Once the bit is unset, the pin will be low. That
> > will make the active low LED turn on. The pin is controlled by the switch
> > PHY. It seems that the PHY controls the pin in the way that it inverts the
> > pin state. That means depending on the wiring of the LED connected to
> > LAN2LED0 on the board, the LED may be on without an active link.
> >
> > To not cause this unwanted behaviour whilst enabling EEE on all boards, set
> > the internal EEE switch bit on the CORE_PLL_GROUP4 register.
> >
> > My testing on MT7531 shows a certain amount of traffic loss when EEE is
> > enabled. That said, I haven't come across a board that enables EEE. So
> > enable EEE on the switch MACs but disable EEE advertisement on the switch
> > PHYs. This way, we don't change the behaviour of the majority of the boards
> > that have this switch. The mediatek-ge PHY driver already disables EEE
> > advertisement on the switch PHYs but my testing shows that it is somehow
> > enabled afterwards. Disabling EEE advertisement before the PHY driver
> > initialises keeps it off.
> >
> > With this change, EEE can now be enabled using ethtool.
> >
> > Fixes: 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features")
> > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
> > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> > ---
> > Here's some information for the record. EEE could not be enabled on MT7531
> > on most boards using ethtool before this. On MT7988 SoC switch, EEE is
> > disabled by default but can be turned on normally using ethtool. EEE is
> > enabled by default on MT7530 and there's no need to make changes on the DSA
> > subdriver for it.
> > ---
> > Changes in v3:
> > - Remove patch 2, it was revealed that it doesn't fix a bug.
> > - Patch 1
> > - Use the internal EEE switch bit provided by SkyLake Huang (黃啟澤). It
> > is a better method compared to unsetting the EEE_DIS bit of the trap as
> > the latter method causes unwanted behaviour on the LED connected to the
> > pin that pertains to the EEE_DIS bit.
>
> Since this leverages something relatively obscure, it would be great if
> someone in the CC list could independently test it. Let's wait a bit
> more.
I've excessively tested this patch on MT7531 today, and reviewed it
today and yesterday. I've also picked it as downstream patch[1] to
OpenWrt, so an even wider audience will have the pleasure of working
EEE on those switch ICs and in-SoC switches.
Tested-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
[1]: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=98f9154316fe8371c709bd11ae8f263e22075ec6
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-04-10 18:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 7:08 [PATCH net v3] net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards Arınç ÜNAL
2024-04-08 7:08 ` Arınç ÜNAL via B4 Relay
2024-04-08 7:08 ` Arınç ÜNAL via B4 Relay
2024-04-09 11:58 ` Paolo Abeni
2024-04-09 11:58 ` Paolo Abeni
2024-04-10 18:52 ` Daniel Golle [this message]
2024-04-10 18:52 ` Daniel Golle
2024-04-11 2:00 ` patchwork-bot+netdevbpf
2024-04-11 2:00 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zhbf6AtfBfxXMIGc@makrotopia.org \
--to=daniel@makrotopia.org \
--cc=SkyLake.Huang@mediatek.com \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=arinc.unal@arinc9.com \
--cc=bartel.eerdekens@constell8.be \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=erkin.bozoglu@xeront.com \
--cc=f.fainelli@gmail.com \
--cc=florian.fainelli@broadcom.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=mithat.guner@xeront.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=opensource@vdorst.com \
--cc=pabeni@redhat.com \
--cc=sean.wang@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.