Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: hujy652@gmail.com
Cc: nbd@nbd.name, lorenzo@kernel.org, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org,
	pabeni@redhat.com, matthias.bgg@gmail.com,
	angelogioacchino.delregno@collabora.com,
	sujuan.chen@mediatek.com, rex.lu@mediatek.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, sashiko-bot@kernel.org
Subject: Re: [PATCH net v6 4/4] net: ethernet: mtk_wed: setup WDMA_RING_TX(0) for non-DBDC MT7986
Date: Thu, 29 Oct 2026 00:59:57 +0000	[thread overview]
Message-ID: <179323559733.3134.3679438988787780948@kernel.org> (raw)
In-Reply-To: <20261026-wedfix-v6-4-a52f6b15d2fc@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The patch adds two early returns to mtk_wed_start() in
  drivers/net/ethernet/mediatek/mtk_wed.c.

--

net: ethernet: mtk_wed: setup WDMA_RING_TX(0) for non-DBDC MT7986

On v2 WED hardware where rx_ring[0] is not allocated (non-DBDC MT7986),
this patch makes mtk_wed_start() program WDMA_RING_TX(0), because WED RX
still sends through that ring. It also adds error messages and early
returns for when the WDMA RX or TX ring setup fails.

> diff --git a/drivers/net/ethernet/mediatek/mtk_wed.c b/drivers/net/ethernet/mediatek/mtk_wed.c
> index 3044a7a8ea03e..f40ac5794341c 100644
> --- a/drivers/net/ethernet/mediatek/mtk_wed.c
> +++ b/drivers/net/ethernet/mediatek/mtk_wed.c
> @@ -2345,7 +2345,20 @@ mtk_wed_start(struct mtk_wed_device *dev, u32 irq_mask)
>  
>  	for (i = 0; i < ARRAY_SIZE(dev->rx_wdma); i++)
>  		if (!dev->rx_wdma[i].desc)
> -			mtk_wed_wdma_rx_ring_setup(dev, i, 16, false);
> +			if (mtk_wed_wdma_rx_ring_setup(dev, i, 16, false)) {
> +				dev_err(dev->hw->dev, "wdma rx ring %d setup failed\n", i);
> +				return;
> +			}
> +
> +	/*
> +	 * non-DBDC MT7986 allocates only rx_ring[1] and tx_wdma[1] during setup
> +	 * but tx_wdma[0] is also needed for WED to function.
> +	 */
> +	if (mtk_wed_is_v2(dev->hw) && !dev->rx_ring[0].desc)
> +		if (mtk_wed_wdma_tx_ring_setup(dev, 0, MTK_WED_WDMA_RING_SIZE, !!dev->tx_wdma[0].desc)) {
> +			dev_err(dev->hw->dev, "wdma tx ring 0 setup failed\n");
> +			return;
> +		}

[Severity: Medium]
Can these early returns leave WED half-configured without the caller
noticing?

mtk_wed_start() is static void, and the ops callback is
void (*start)(struct mtk_wed_device *dev, u32 irq_mask), so the error
goes no further than this function.

Both returns happen after mtk_wed_rx_buffer_alloc() has succeeded, and
maybe after some WDMA_RING_RX(i) and MTK_WED_WDMA_RING_RX(i) registers
have been written. They then skip mtk_wed_hw_init(),
mtk_wed_configure_irq(), mtk_wed_set_ext_int(), mtk_wed_dma_enable() and
dev->running = true.

In mt76, mt7915_dma_start() has already written the WED IRQ mask to
MT_INT_MASK_CSR or MT_INT_WED_MASK_CSR. It then continues as if WED were
running:

drivers/net/wireless/mediatek/mt76/mt7915/dma.c:mt7915_dma_start() {
    ...
		mtk_wed_device_start(&dev->mt76.mmio.wed, wed_irq_mask);
	}

	irq_mask = reset ? MT_INT_MCU_CMD : irq_mask;

	mt7915_irq_enable(dev, irq_mask);
	mt7915_irq_disable(dev, 0);

	return 0;
}

mtk_wed_device_active() is just !!(_dev)->ops. So the WLAN driver keeps
sending traffic and IRQ handling through a WED whose DMA was never
enabled, and the only sign is the dev_err in the log. mt7996 calls
mtk_wed_device_start() the same way.

The rx_wdma change also alters behavior that is unrelated to the
WDMA_RING_TX(0) fix. Before this patch, a failed rx_wdma allocation left
only that one WDMA RX ring unprogrammed, and WED still started. Now one
dma_alloc_coherent() failure in mtk_wed_ring_alloc() stops the whole WED
datapath from being enabled.

This can only happen on the first start under allocation failure. SER
restarts reuse the rings that were already allocated.

The commit message says "add error messages and bail when mtk_wed_start
fails". It does not mention that callers cannot see the bail, or that no
state is rolled back.

Would it be better to propagate the error? For example, the start op
could return int and the mt7915/mt7996 dma_start paths could handle the
failure. Another option is to fall back to non-WED operation.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261026-wedfix-v6-0-a52f6b15d2fc%40gmail.com


      reply	other threads:[~2026-10-29  1:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-26  9:57 [PATCH net v6 0/4] net: ethernet: mtk_wed: misc fixes Zhi-Jun You
2026-10-26  9:57 ` [PATCH net v6 1/4] net: ethernet: mtk_wed: skip ring reset in wdma_tx_ring_setup for WED v3 Zhi-Jun You
2026-10-26  9:57 ` [PATCH net v6 2/4] net: ethernet: mtk_wed: fix reset condition for rx wdma Zhi-Jun You
2026-10-26  9:57 ` [PATCH net v6 3/4] net: ethernet: mtk_wed: free up rings during detach Zhi-Jun You
2026-10-29  0:59   ` netdev-bot+sashiko
2026-10-26  9:57 ` [PATCH net v6 4/4] net: ethernet: mtk_wed: setup WDMA_RING_TX(0) for non-DBDC MT7986 Zhi-Jun You
2026-10-29  0:59   ` netdev-bot+sashiko [this message]

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=179323559733.3134.3679438988787780948@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=hujy652@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=lorenzo@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rex.lu@mediatek.com \
    --cc=sashiko-bot@kernel.org \
    --cc=sujuan.chen@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox