[PATCH] Backport mt7621 ethernet driver fixes to prevent freezes

[mail at adrianschmutzler.de]

Hi,

> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf
> Of Fabian Bläse
> Sent: Sonntag, 2. August 2020 19:55
> To: franken-dev at freifunk.net
> Subject: [PATCH] Backport mt7621 ethernet driver fixes to prevent freezes
> 
> Currently devices based on mt7621 might freeze due to issues with the
> ethernet driver. (see [1])
> 
> This patch might fix these freezes and will be included in OpenWrt 19.07.4
> [2].
> While it is hard to reproduce the issue and this patch is therefore not verified
> to fix the issue, it is backported into our firmware anyway.
> 
> This patch can be removed when upgrading to OpenWrt 19.07.4.
> 
> [1] https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-
> r11573
> [2]
> https://github.com/openwrt/openwrt/commit/c8f8e59816eca49d776562d2d
> 302bf990a87faf0

Hier könnte man den tatsächlichen Link vom Backport nehmen, und nicht vom master:

https://github.com/openwrt/openwrt/commit/498f1f4f5df2d077ba524f5735906bb52c12d580

Acked-by: Adrian Schmutzler <freifunk at adrianschmutzler.de>

Grüße

Adrian

> 
> Signed-off-by: Fabian Bläse <fabian at blaese.de>
> ---
>  .../0010-ramips-gsw_mt7621-disable-PORT.patch | 58
> +++++++++++++++++++
>  1 file changed, 58 insertions(+)
>  create mode 100644 build_patches/openwrt/0010-ramips-gsw_mt7621-
> disable-PORT.patch
> 
> diff --git a/build_patches/openwrt/0010-ramips-gsw_mt7621-disable-
> PORT.patch b/build_patches/openwrt/0010-ramips-gsw_mt7621-disable-
> PORT.patch
> new file mode 100644
> index 0000000..7e6c540
> --- /dev/null
> +++ b/build_patches/openwrt/0010-ramips-gsw_mt7621-disable-
> PORT.patch
> @@ -0,0 +1,58 @@
> +From 498f1f4f5df2d077ba524f5735906bb52c12d580 Mon Sep 17 00:00:00
> 2001
> +From: =?UTF-8?q?Petr=20=C5=A0tetiar?= <ynezz at true.cz>
> +Date: Tue, 11 Feb 2020 11:17:41 +0100
> +Subject: [PATCH] ramips: gsw_mt7621: disable PORT 5 MAC RX/TX flow
> +control by  default
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Looking at the current upstream driver implementation, it seems like
> +the TX/RX flow control is enabled only if the flow control pause option
> +is resolved from the device/link partner advertisements (or otherwise set).
> +
> +On the other hand, our current in-tree driver force enables TX/RX flow
> +control by default, thus possibly leading to TX timeouts if the other
> +end sends pause frames (which are not properly handled?):
> +
> + WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:320
> + dev_watchdog+0x1ac/0x324 NETDEV WATCHDOG: eth0 (mtk_soc_eth):
> transmit
> + queue 0 timed out
> +
> +Disabling the flow control on PORT 5 MAC seems to fix this issues as
> +the pause frames are then filtered out. While at it, I'm removing the
> +if condition completely as suggested, since this code is run only on
> +mt7621 SoC, so there is no need to check for the silicon revisions.
> +
> +Ref:
> +https://lists.openwrt.org/pipermail/openwrt-devel/2017-
> November/009882.
> +html
> +Ref:
> +https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-
> r11573/5
> +0000/12
> +Suggested-by: Felix Fietkau <nbd at nbd.name>
> +Reported-by: Rosen Penev <rosenp at gmail.com>
> +Signed-off-by: Petr Štetiar <ynezz at true.cz> (cherry picked from commit
> +c8f8e59816eca49d776562d2d302bf990a87faf0)
> +---
> + .../drivers/net/ethernet/mediatek/gsw_mt7621.c       | 12 +++---------
> + 1 file changed, 3 insertions(+), 9 deletions(-)
> +
> +diff --git
> +a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt76
> +21.c
> +b/target/linux/ramips/files-
> 4.14/drivers/net/ethernet/mediatek/gsw_mt76
> +21.c index 89be23900738..232bcd8cf4ea 100644
> +---
> +a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt76
> +21.c
> ++++ b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_
> ++++ mt7621.c
> +@@ -98,15 +98,9 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw,
> struct device_node *np)
> + 	mt7530_mdio_w32(gsw, 0x7000, 0x3);
> + 	usleep_range(10, 20);
> +
> +-	if ((rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0xFFFF) == 0x0101) {
> +-		/* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */
> +-		mtk_switch_w32(gsw, 0x2305e30b,
> GSW_REG_MAC_P0_MCR);
> +-		mt7530_mdio_w32(gsw, 0x3600, 0x5e30b);
> +-	} else {
> +-		/* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */
> +-		mtk_switch_w32(gsw, 0x2305e33b,
> GSW_REG_MAC_P0_MCR);
> +-		mt7530_mdio_w32(gsw, 0x3600, 0x5e33b);
> +-	}
> ++	/* (GE1, Force 1000M/FD, FC OFF, MAX_RX_LENGTH 1536) */
> ++	mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR);
> ++	mt7530_mdio_w32(gsw, 0x3600, 0x5e30b);
> +
> + 	/* (GE2, Link down) */
> + 	mtk_switch_w32(gsw, 0x8000, GSW_REG_MAC_P1_MCR);
> --
> 2.28.0
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : openpgp-digital-signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20200802/3d2ba700/attachment.sig>