From: Cunhao Lu <1579567540@qq.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
kernel@pengutronix.de, Vincent Mailhol <mailhol@kernel.org>,
Heiko Stuebner <heiko@sntech.de>
Cc: linux-can@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Cunhao Lu <1579567540@qq.com>
Subject: [PATCH v2 0/3] can: rockchip_canfd: fix TX stalls and races
Date: Thu, 30 Jul 2026 18:11:45 +0800 [thread overview]
Message-ID: <tencent_D802EB485A801362BF9F54130C0D990C6206@qq.com> (raw)
While running CAN traffic on an RK3588 system, the driver repeatedly
reported an inconsistent TX echo state:
rockchip_canfd fea60000.can can0: rkcanfd_tx_tail_is_eff:
echo_skb[0]=NULL tx_head=0x00060f7d tx_tail=0x00060f7c
The Rockchip CAN-FD driver completes transmissions by matching
self-received frames with entries in the echo skb ring. The warning above
is emitted when the driver sees a pending transmission but finds no skb in
the corresponding echo slot.
The immediate cause is a race between the transmit and completion paths.
The completion path removes an echo skb before advancing tx_tail, while
the transmit path reads tx_head, tx_tail and that echo slot without common
synchronization. It can therefore observe a partially updated state,
dereference an skb which has been queued for NAPI, or stop the TX queue
without a later completion to wake it.
Two additional TX stall paths were found. The transmit path submits a
frame and advances tx_head even if installing its echo skb fails. In
addition, the erratum 6 retry path selects tx_head, which denotes the next
free buffer with a two-entry FIFO, instead of retrying the outstanding
buffer at tx_tail.
Review also identified that the erratum 12 MODE/CMD/MODE sequence can be
interleaved between the transmit softirq and the RX interrupt retry path.
The interrupt can restore the default MODE before the softirq issues CMD,
bypassing the SPACE_RX_MODE workaround.
This series makes echo skb setup failure abort the transmission, retries
the correct hardware buffer, and uses a spinlock to serialize the TX head,
tail, echo ring and command register sequence.
The final series was tested on an RK3588 rev2.2 at 1 Mbit/s with 100,000
extended CAN frames. The run triggered 138 erratum 6 retries and completed
without drops, queue stalls or driver warnings. RK3588 does not enable
erratum 12, so this test does not exercise that hardware workaround.
All three patches pass scripts/checkpatch.pl --strict. The Rockchip CAN-FD
module also builds cleanly with W=1.
---
Changes in v2:
- Document that the TX lock also serializes the erratum 12 MODE/CMD/MODE
sequence.
- Add the erratum 12 commit to the Fixes tags of patch 3.
- Add RK3588 extended-frame stress-test results.
- Link to v1:
https://lore.kernel.org/linux-can/tencent_0E5C2332F801372DD0D4CB4C25B88C18040A@qq.com
---
Cunhao Lu (3):
can: rockchip_canfd: prevent TX stall on echo skb failure
can: rockchip_canfd: retry the outstanding TX buffer
can: rockchip_canfd: serialize TX state and command writes
drivers/net/can/rockchip/rockchip_canfd-core.c | 1 +
drivers/net/can/rockchip/rockchip_canfd-rx.c | 31 +++++++++++++-----
drivers/net/can/rockchip/rockchip_canfd-tx.c | 44 ++++++++++++++++++++++----
drivers/net/can/rockchip/rockchip_canfd.h | 4 ++-
4 files changed, 64 insertions(+), 16 deletions(-)
---
base-commit: 11028ab62899e4191e074ee364c712b77823a9c4
change-id: 20260730-master-a1b54b3cf5a0
Best regards,
--
Cunhao Lu <1579567540@qq.com>
next reply other threads:[~2026-07-30 10:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 10:11 Cunhao Lu [this message]
[not found] <20260730-master-v2-0-572974052400@qq.com>
2026-07-30 10:11 ` [PATCH v2 1/3] can: rockchip_canfd: prevent TX stall on echo skb failure Cunhao Lu
2026-07-30 11:38 ` Marc Kleine-Budde
2026-07-30 12:39 ` Cunhao Lu
2026-07-30 10:11 ` [PATCH v2 2/3] can: rockchip_canfd: retry the outstanding TX buffer Cunhao Lu
2026-07-30 10:11 ` [PATCH v2 3/3] can: rockchip_canfd: serialize TX state and command writes Cunhao Lu
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=tencent_D802EB485A801362BF9F54130C0D990C6206@qq.com \
--to=1579567540@qq.com \
--cc=heiko@sntech.de \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mailhol@kernel.org \
--cc=mkl@pengutronix.de \
--cc=stable@vger.kernel.org \
/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
all inboxes | Powered by JetHome®