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.gor...@gmail.com> wrote:
>
> Hi,
>
> On Sat, Mar 8, 2025 at 7:01 PM Qingfang Deng <dqf...@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 <dqf...@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 <dqf...@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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
