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: 33+ 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
2026-07-09 10:53 ` Jack Wu via B4 Relay
2026-07-09 10:53 ` [PATCH v4 1/7] net: wwan: t9xx: Add PCIe core Jack Wu
2026-07-09 10:53 ` 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
2026-07-09 10:53 ` 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
2026-07-09 10:53 ` 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
2026-07-09 10:53 ` 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
2026-07-09 10:53 ` 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
2026-07-09 10:53 ` 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
2026-07-09 10:53 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.