From: Patrick Zhang <patrzhan@amazon.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
Vincent Mailhol <mailhol@kernel.org>, <linux-can@vger.kernel.org>
Cc: Pavel Pisa <pisa@cmp.felk.cvut.cz>,
Ondrej Ille <ondrej.ille@gmail.com>, Harini T <harini.t@amd.com>,
Michal Simek <michal.simek@amd.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: [PATCH 1/3] can: ctucanfd: enable NAPI before starting the controller
Date: Wed, 21 Oct 2026 20:59:22 +0000 [thread overview]
Message-ID: <20261021205924.2538511-2-patrzhan@amazon.com> (raw)
In-Reply-To: <20261021205924.2538511-1-patrzhan@amazon.com>
ctucan_open() starts the controller and unmasks RBNEI in
ctucan_chip_start(), prints "ctu_can_fd device registered", and only
then calls napi_enable(). A frame that arrives in that window raises
RBNEI. ctucan_interrupt() masks RBNEI and calls napi_schedule(). NAPI is
still disabled, so napi_schedule_prep() finds NAPI_STATE_SCHED set and
the schedule is dropped. napi_enable() then clears SCHED without
scheduling anything. Only ctucan_rx_poll() unmasks RBNEI again, and it
never runs. The interface receives nothing until the next close.
Transmit still works. The RX FIFO fills up and the core sets DOR, but
the overrun is only accounted in ctucan_rx_poll(), so rx_errors and
rx_over_errors stay at zero and nothing is logged. Every re-open (ip
link down/up, a driver rebind) runs the same race again.
The netdev_info() in the window makes it much wider on a slow console.
This can be reproduced by sending continuous traffic with cangen from
another node and repeating "ip link set down/up" on the test device.
Enable NAPI before the controller starts, so that an early RX interrupt
can schedule the poll. NAPI can be enabled while the controller is in
reset, because nothing schedules it until an interrupt arrives. If
ctucan_chip_start() fails, disable NAPI again. Otherwise the next open
would call napi_enable() on an already enabled instance and trip the
BUG_ON() in napi_enable_locked().
Tested on QEMU with the ctucan_pci device.
Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Patrick Zhang <patrzhan@amazon.com>
---
drivers/net/can/ctucanfd/ctucanfd_base.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/ctucanfd/ctucanfd_base.c b/drivers/net/can/ctucanfd/ctucanfd_base.c
index 07d4aa43c..82bf6c645 100644
--- a/drivers/net/can/ctucanfd/ctucanfd_base.c
+++ b/drivers/net/can/ctucanfd/ctucanfd_base.c
@@ -1231,6 +1231,10 @@ static int ctucan_open(struct net_device *ndev)
goto err_irq;
}
+ /* Keep before ctucan_chip_start(): the ISR masks RBNEI and only the
+ * poll unmasks it.
+ */
+ napi_enable(&priv->napi);
ret = ctucan_chip_start(ndev);
if (ret < 0) {
netdev_err(ndev, "ctucan_chip_start failed!\n");
@@ -1238,12 +1242,12 @@ static int ctucan_open(struct net_device *ndev)
}
netdev_info(ndev, "ctu_can_fd device registered\n");
- napi_enable(&priv->napi);
netif_start_queue(ndev);
return 0;
err_chip_start:
+ napi_disable(&priv->napi);
free_irq(ndev->irq, ndev);
err_irq:
close_candev(ndev);
base-commit: a7bfaba4823e3c165bb2004c74eff7c096672bc7
--
2.50.1
next prev parent reply other threads:[~2026-10-21 21:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 20:59 [PATCH 0/3] can: enable NAPI before starting the controller in three drivers Patrick Zhang
2026-10-21 20:59 ` Patrick Zhang [this message]
2026-10-21 20:59 ` [PATCH 2/3] can: xilinx_can: enable NAPI before starting the controller Patrick Zhang
2026-10-21 20:59 ` [PATCH 3/3] can: ifi_canfd: " Patrick Zhang
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=20261021205924.2538511-2-patrzhan@amazon.com \
--to=patrzhan@amazon.com \
--cc=harini.t@amd.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=michal.simek@amd.com \
--cc=mkl@pengutronix.de \
--cc=ondrej.ille@gmail.com \
--cc=pisa@cmp.felk.cvut.cz \
--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®