From: sashiko-bot@kernel.org
To: "Ciprian Costea" <ciprianmarian.costea@oss.nxp.com>
Cc: "Marc Kleine-Budde" <mkl@pengutronix.de>,
"Vincent Mailhol" <mailhol@kernel.org>,
Frank.Li@kernel.org, imx@lists.linux.dev, robh@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
"Oliver Hartkopp" <socketcan@hartkopp.net>,
linux-can@vger.kernel.org,
"Oleksij Rempel" <o.rempel@pengutronix.de>
Subject: Re: [PATCH v7 5/6] can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
Date: Mon, 31 Aug 2026 18:51:22 +0000 [thread overview]
Message-ID: <20260831185123.165B21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260831143449.12828-6-ciprianmarian.costea@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Wakeup interrupt is not configured for the new dedicated ESR IRQ during suspend.
Pre-existing issues:
- [Critical] Concurrent execution of separate IRQ handlers corrupts the lockless rx-offload SKB queue.
--
commit 53e92dd64634f7bc681782eddd379791f6533960
Author: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
This commit introduces the FLEXCAN_QUIRK_IRQ_BERR quirk for platforms where bus
errors and state changes share a dedicated IRQ line. It adds a combined IRQ
handler flexcan_irq_esr() and updates interrupt setup and teardown to manage
the new line.
> diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
> index f28ff0e95b74f..601d88bfcfeb2 100644
> --- a/drivers/net/can/flexcan/flexcan-core.c
> +++ b/drivers/net/can/flexcan/flexcan-core.c
[ ... ]
> @@ -1303,6 +1303,22 @@ static irqreturn_t flexcan_irq_boff(int irq, void *dev_id)
> return handled;
> }
>
> +/* Combined bus error and state change IRQ handler */
> +static irqreturn_t flexcan_irq_esr(int irq, void *dev_id)
> +{
> + struct net_device *dev = dev_id;
> + struct flexcan_priv *priv = netdev_priv(dev);
> + irqreturn_t handled;
> +
> + handled = flexcan_do_state(dev);
> + handled |= flexcan_do_berr(dev);
> +
> + if (handled)
> + can_rx_offload_irq_finish(&priv->offload);
> +
> + return handled;
> +}
[Severity: Critical]
This is a pre-existing issue, but adding this separate IRQ handler highlights
a race condition. Can this new handler and the main mailbox IRQ handler
execute concurrently on different CPUs?
If dev->irq and priv->irq_err are dispatched to different CPUs simultaneously,
both handlers can call into the Rx offload functions in rx-offload.c. For
example:
CPU1 (in flexcan_irq_mb):
can_rx_offload_irq_offload_timestamp()
__skb_queue_add_sort(&offload->skb_irq_queue, ...)
CPU2 (in flexcan_irq_esr):
handled |= flexcan_do_berr(dev);
flexcan_irq_bus_err()
can_rx_offload_queue_timestamp()
__skb_queue_add_sort(&offload->skb_irq_queue, ...)
Since the Rx offload queue manipulation in __skb_queue_add_sort() is lockless,
could this concurrent execution corrupt the skb_irq_queue list and crash the
kernel? Similarly, both paths call can_rx_offload_irq_finish() which splices
the queue locklessly from the IRQ queue side without adequate mutual exclusion
against other HardIRQs.
[ ... ]
> @@ -1905,6 +1922,13 @@ static int flexcan_open(struct net_device *dev)
> goto out_free_irq_boff;
> }
>
> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_IRQ_BERR) {
> + err = request_irq(priv->irq_err,
> + flexcan_irq_esr, IRQF_SHARED, dev->name, dev);
> + if (err)
> + goto out_free_irq_boff;
> + }
> +
[Severity: Medium]
Since this quirk routes the wakeup event (WAK_INT) to this new dedicated ESR
IRQ line, should priv->irq_err be configured for wakeup during suspend?
Currently, flexcan_suspend() calls enable_irq_wake(dev->irq), but it does
not arm priv->irq_err. Will the system fail to wake up from sleep upon CAN
activity on platforms using this quirk because the interrupt controller isn't
armed for the correct line?
Should flexcan_suspend() and flexcan_resume() be updated to handle
priv->irq_err as well?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260831143449.12828-1-ciprianmarian.costea@oss.nxp.com?part=5
next prev parent reply other threads:[~2026-08-31 18:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 14:34 [PATCH v7 0/6] can: flexcan: Add NXP S32N79 SoC support Ciprian Costea
2026-08-31 14:34 ` [PATCH v7 1/6] can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms Ciprian Costea
2026-08-31 18:01 ` sashiko-bot
2026-09-01 14:44 ` Ciprian Marian Costea
2026-08-31 14:34 ` [PATCH v7 2/6] can: flexcan: disable all IRQ lines in flexcan_chip_interrupts_enable() Ciprian Costea
2026-08-31 18:15 ` sashiko-bot
2026-08-31 14:34 ` [PATCH v7 3/6] can: flexcan: split rx/tx masks per mailbox IRQ line Ciprian Costea
2026-08-31 18:27 ` sashiko-bot
2026-08-31 14:34 ` [PATCH v7 4/6] dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support Ciprian Costea
2026-08-31 18:37 ` sashiko-bot
2026-08-31 14:34 ` [PATCH v7 5/6] can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk Ciprian Costea
2026-08-31 18:51 ` sashiko-bot [this message]
2026-08-31 14:34 ` [PATCH v7 6/6] can: flexcan: add NXP S32N79 SoC support Ciprian Costea
2026-08-31 19:01 ` sashiko-bot
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=20260831185123.165B21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=ciprianmarian.costea@oss.nxp.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=linux-can@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mkl@pengutronix.de \
--cc=o.rempel@pengutronix.de \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=socketcan@hartkopp.net \
/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