[PATCH] kernel: Mediatek: fix EEE registers init
Felix Baumann
felix.baumann at freifunk-aachen.de
Fri Mar 21 04:10:57 PDT 2025
Am 14. März 2025 02:56:59 MEZ schrieb Qingfang Deng <dqfext at gmail.com>:
>Hi Daniel,
>
>On Fri, Mar 14, 2025 at 3:42 AM Daniel Golle <daniel at makrotopia.org> wrote:
>>
>> Hi Qingfang,
>>
>> I've been testing EEE support on MT7986 as well as MT7988 with your
>> patches on top of OpenWrt's Linux 6.6.82.
>>
>> I noticed that while the LPI timer of the MT753x DSA switch ports is
>> 30us by default it is deplayed as 0us on the SoC's Ethernet ports, which
>> seems wrong... I guess this should be fixed as well.
>
>This patch sets the default to 1000 us. Does it still read 0 us on your end?
>
>>
>>
>> Cheers
>>
>> Daniel
>>
>>
>> On Wed, Mar 12, 2025 at 10:40:55PM +0800, Qingfang Deng wrote:
>> > Hi Jonas,
>> >
>> > Due to major API changes upstream, the feature wasn't backported as-is.
>> > https://web.git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=952d7325362ffbefa6ce5619fb4e53c2159ec7a7
>> >
>> > The original commit does not need fixes.
>> >
>> > Regards,
>> > Qingfang
>> >
>> > [Resent as plaintext mode]
>> >
>> >
>> > On Wed, Mar 12, 2025 at 10:21 PM Jonas Gorski <jonas.gorski at gmail.com> wrote:
>> > >
>> > > Hi,
>> > >
>> > > On Sat, Mar 8, 2025 at 7:01 PM Qingfang Deng <dqfext at gmail.com> wrote:
>> > > >
>> > > > After booting, a "transmit queue 0 timed out" warning followed by a
>> > > > register dump was observed. The dump indicates that mtk_hw_init() does
>> > > > not initialize the EEECR during probe. This occurs because the
>> > > > netdev is allocated in mtk_add_mac(), which is called after
>> > > > mtk_hw_init(). Consequently, the EEECR register remains uninitialized
>> > > > until a reset is triggered, causing mtk_hw_init() to run again with a
>> > > > valid netdev, at which point the register is finally set.
>> > > >
>> > > > To address this, instead of modifying the probe sequence, latch the Tx
>> > > > LPI enable state and timer value, and move the EEECR register
>> > > > initialization to mtk_mac_link_up() to ensure proper setup when the
>> > > > interface comes up.
>> > > >
>> > > > Additionally, the splat reveals that LPI functionality is controlled by
>> > > > the MAC_MCR_EEE bits in the MCR register. Update mtk_set_eee() to
>> > > > modify these bits accordingly.
>> > > >
>> > > > Fixes: d8315d5358d5 ("kernel: backport Mediatek SoC EEE support")
>> > > > Fixes: edddbaf79ccf ("kernel: Mediatek: set default EEE Tx LPI timer")
>> > > > Signed-off-by: Qingfang Deng <dqfext at gmail.com>
>> > > > ---
>> > > > ...et-ethernet-mediatek-add-EEE-support.patch | 57 ++++++++++++-------
>> > > > ..._eth_soc-add-hw-dump-for-forced-rese.patch | 4 +-
>> > > > ...net-mtk_eth_soc-enable-threaded-NAPI.patch | 2 +-
>> > > > ..._eth_soc-reset-all-TX-queues-on-DMA-.patch | 2 +-
>> > > > ..._eth_soc-compile-out-netsys-v2-code-.patch | 4 +-
>> > > > ..._eth_soc-work-around-issue-with-send.patch | 6 +-
>> > > > ...ernet-mtk_eth_soc-use-napi_build_skb.patch | 4 +-
>> > > > ...-mediatek-enlarge-DMA-reserve-buffer.patch | 2 +-
>> > > > ..._eth_soc-fix-memory-corruption-durin.patch | 2 +-
>> > > > ..._eth_soc-add-paths-and-SerDes-modes-.patch | 26 ++++-----
>> > > > ...th_soc-reduce-rx-ring-size-for-older.patch | 16 +++---
>> > > > ..._eth_soc-do-not-enable-page-pool-sta.patch | 4 +-
>> > > > 12 files changed, 71 insertions(+), 58 deletions(-)
>> > > >
>> > > > diff --git a/target/linux/generic/backport-6.6/753-v6.15-net-ethernet-mediatek-add-EEE-support.patch b/target/linux/generic/backport-6.6/753-v6.15-net-ethernet-mediatek-add-EEE-support.patch
>> > > > index d9b86ae36e..b908d133b5 100644
>> > > > --- a/target/linux/generic/backport-6.6/753-v6.15-net-ethernet-mediatek-add-EEE-support.patch
>> > > > +++ b/target/linux/generic/backport-6.6/753-v6.15-net-ethernet-mediatek-add-EEE-support.patch
>> > > > @@ -23,34 +23,23 @@ Signed-off-by: Qingfang Deng <dqfext at gmail.com>
>> > > > MAC_MCR_FORCE_DPX | MAC_MCR_FORCE_TX_FC |
>> > > > MAC_MCR_FORCE_RX_FC);
>> > > >
>> > > > -@@ -811,6 +812,18 @@ static void mtk_mac_link_up(struct phyli
>> > > > +@@ -811,6 +812,15 @@ static void mtk_mac_link_up(struct phyli
>> > > > if (rx_pause)
>> > > > mcr |= MAC_MCR_FORCE_RX_FC;
>> > > >
>> > > > -+ if (mode == MLO_AN_PHY && phy && phy_init_eee(phy, false) >= 0) {
>> > > > -+ switch (speed) {
>> > > > -+ case SPEED_2500:
>> > > > -+ case SPEED_1000:
>> > > > -+ mcr |= MAC_MCR_EEE1G;
>> > > > -+ break;
>> > > > -+ case SPEED_100:
>> > > > -+ mcr |= MAC_MCR_EEE100M;
>> > > > -+ break;
>> > > > -+ }
>> > > > ++ if (mode == MLO_AN_PHY && phy && mac->tx_lpi_enabled && phy_init_eee(phy, false) >= 0) {
>> > > > ++ mcr |= MAC_MCR_EEE100M | MAC_MCR_EEE1G;
>> > > > ++ mtk_w32(mac->hw,
>> > > > ++ FIELD_PREP(MAC_EEE_WAKEUP_TIME_1000, 17) |
>> > > > ++ FIELD_PREP(MAC_EEE_WAKEUP_TIME_100, 36) |
>> > > > ++ FIELD_PREP(MAC_EEE_LPI_TXIDLE_THD, mac->txidle_thd_ms),
>> > > > ++ MTK_MAC_EEECR(mac->id));
>> > > > + }
>> > > > +
>> > >
>> > > Please don't modify backported patches, they represent upstream
>> > > accepted changes, so they are immutable in that regard (apart from
>> > > required changes for adapting them to older kernels).
>> > >
>> > > Just add a patch on top that fixes the behavior, and ideally also send
>> > > it upstream to netdev so it gets proper review etc.
>> > >
>> > > Best Regards,
>> > > Jonas
>> >
>> > _______________________________________________
>> > openwrt-devel mailing list
>> > openwrt-devel at lists.openwrt.org
>> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>_______________________________________________
>openwrt-devel mailing list
>openwrt-devel at lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi,
it would be great if this could be moved along. Reading bug reports this breaks usage of snapshots for quite a few users of filogic.
Daniel it would be great if you could answer Qingfang's question so they could adjust their patch if necessary.
Apart from that there doesn't appear to speak anything against merging this, right? I mean this patch only adjusts an upstream patch to account for kernel 6.6 still using an older API that was reworked upstream. Sounds reasonable to me. Not something that needs to be discussed upstream since the feature is not going to be backported there.
Regards
Felix Baumann
More information about the openwrt-devel
mailing list