Linux-mediatek Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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