From: "Wu. JackBB (GSM)" <JackBB_Wu@compal.com>
To: Simon Horman <horms@kernel.org>
Cc: "loic.poulain@oss.qualcomm.com" <loic.poulain@oss.qualcomm.com>,
"ryazanov.s.a@gmail.com" <ryazanov.s.a@gmail.com>,
"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"wen-zhi.huang@mediatek.com" <wen-zhi.huang@mediatek.com>,
"shi-wei.yeh@mediatek.com" <shi-wei.yeh@mediatek.com>,
"Minano.tseng@mediatek.com" <Minano.tseng@mediatek.com>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"angelogioacchino.delregno@collabora.com"
<angelogioacchino.delregno@collabora.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"skhan@linuxfoundation.org" <skhan@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: RE: [External Mail] Re: [PATCH v4 3/7] net: wwan: t9xx: Add control DMA interface
Date: Fri, 17 Jul 2026 10:57:59 +0000 [thread overview]
Message-ID: <b1bc657dfd584ebfbe126ed7b1c25aa2@compal.com> (raw)
In-Reply-To: <cacde4a05d6a48afbac6425425fe180c@compal.com>
Hi Simon,
After further internal review, we are correcting several
responses from our previous reply. The following items will
be fixed in v5.
On [date] Jack Wu wrote:
>> [Severity: High]
>> Is a dma_rmb() needed after checking the hardware ownership flag?
> The GPD descriptors are allocated from a coherent DMA pool
> (dma_pool_zalloc), so CPU cache coherency is guaranteed by the DMA
> mapping. A dma_rmb() is not needed because coherent memory ensures
> the CPU always observes the latest values written by the device.
We Will remove the rmb() and add dma_rmb() after the HWO check in
both TX and RX done paths:
/* TX done */
if (!req->data_vm_addr ||
(req->gpd->tx_gpd.gpd_flags & CLDMA_GPD_FLAG_HWO))
break;
dma_rmb();
/* RX done */
if (req->gpd->rx_gpd.gpd_flags & CLDMA_GPD_FLAG_HWO)
break;
dma_rmb();
mtk_cldma_rx_skb_adjust(mdev, rxq, req);
>> [Severity: High]
>> If mtk_cldma_reload_rx_skb fails due to memory pressure, it jumps
>> to out without advancing rxq->free_idx.
> If mtk_cldma_reload_rx_skb() fails, the code jumps to "out" which
> unmasks the interrupt. On the next hardware interrupt, rx_done_work
> runs again and retries from the same free_idx.
Will change the failure path to recycle the old buffer and return
the descriptor to hardware, dropping the current packet to
guarantee forward progress.
>> [Severity: High]
>> Does this code safely handle non-linear SKBs?
> When nr_bds == 0, the SKB is always linear — it is allocated
> internally via __dev_alloc_skb() with data copied via skb_put().
Will change skb->len to skb_headlen(skb).
>> [Severity: High]
>> Could there be a race condition here with mtk_cldma_tx_done_work?
> No race exists. tx_done_work sees HWO still set.
Will add a free_idx == wr_idx boundary check at the top of the
done_work loop (using READ_ONCE/WRITE_ONCE) to prevent done_work
from crossing into submit territory on descriptor reuse.
Thanks
next prev parent reply other threads:[~2026-07-17 10:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 10:53 [PATCH v4 0/7] net: wwan: t9xx: Add MediaTek T9XX WWAN driver Jack Wu via B4 Relay
2026-07-09 10:53 ` [PATCH v4 1/7] net: wwan: t9xx: Add PCIe core Jack Wu via B4 Relay
2026-07-16 9:33 ` Simon Horman
2026-07-17 6:25 ` [External Mail] " Wu. JackBB (GSM)
2026-07-17 10:51 ` Wu. JackBB (GSM)
2026-07-09 10:53 ` [PATCH v4 2/7] net: wwan: t9xx: Add control plane transaction layer Jack Wu via B4 Relay
2026-07-16 9:33 ` Simon Horman
2026-07-17 6:27 ` [External Mail] " Wu. JackBB (GSM)
2026-07-17 10:53 ` Wu. JackBB (GSM)
2026-07-09 10:53 ` [PATCH v4 3/7] net: wwan: t9xx: Add control DMA interface Jack Wu via B4 Relay
2026-07-16 9:34 ` Simon Horman
2026-07-17 6:37 ` [External Mail] " Wu. JackBB (GSM)
2026-07-17 10:57 ` Wu. JackBB (GSM) [this message]
2026-07-09 10:53 ` [PATCH v4 4/7] net: wwan: t9xx: Add control port Jack Wu via B4 Relay
2026-07-16 9:34 ` Simon Horman
2026-07-17 7:20 ` [External Mail] " Wu. JackBB (GSM)
2026-07-17 11:00 ` Wu. JackBB (GSM)
2026-07-09 10:53 ` [PATCH v4 5/7] net: wwan: t9xx: Add FSM thread Jack Wu via B4 Relay
2026-07-16 9:34 ` Simon Horman
2026-07-17 7:24 ` [External Mail] " Wu. JackBB (GSM)
2026-07-17 11:02 ` Wu. JackBB (GSM)
2026-07-09 10:53 ` [PATCH v4 6/7] net: wwan: t9xx: Add AT & MBIM WWAN ports Jack Wu via B4 Relay
2026-07-16 9:34 ` Simon Horman
2026-07-17 7:26 ` [External Mail] " Wu. JackBB (GSM)
2026-07-09 10:53 ` [PATCH v4 7/7] net: wwan: t9xx: Add maintainers entry Jack Wu via B4 Relay
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=b1bc657dfd584ebfbe126ed7b1c25aa2@compal.com \
--to=jackbb_wu@compal.com \
--cc=Minano.tseng@mediatek.com \
--cc=andrew+netdev@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=loic.poulain@oss.qualcomm.com \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ryazanov.s.a@gmail.com \
--cc=shi-wei.yeh@mediatek.com \
--cc=skhan@linuxfoundation.org \
--cc=wen-zhi.huang@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