Thread (11 messages) 11 messages, 2 authors, 2026-03-19

Re: [PATCH v2 0/5] can: flexcan: Add NXP S32N79 SoC support

From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Date: 2026-03-19 14:14:53
Also in: imx, linux-can, linux-devicetree, lkml

On 3/19/2026 1:56 PM, Marc Kleine-Budde wrote:
On 19.03.2026 10:40:27, Ciprian Costea wrote:
quoted
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>

This patch series adds FlexCAN support for the NXP S32N79 SoC.

The S32N79 is an automotive-grade processor from NXP with multiple
FlexCAN instances. The FlexCAN IP integration on S32N79 differs from
other SoCs in the interrupt routing - it uses two separate interrupt
lines:
   - one interrupt for mailboxes 0-127
   - one interrupt for bus error detection and device state changes

The CAN controllers are connected through an irqsteer interrupt
controller in the RCU (Resource Control Unit) domain.

This series:
   1. Adds dt-bindings documentation for S32N79 FlexCAN
   2. Introduces FLEXCAN_QUIRK_IRQ_BERR to handle the two-interrupt
      configuration
   3. Adds S32N79 device data and compatible string to the driver
   4. Adds FlexCAN device tree nodes for S32N79 SoC
   5. Enables FlexCAN devices on the S32N79-RDB board

Tested on S32N79-RDB board with CAN and CAN FD communication.
I think DTS changes go into a separate series.
Hi Marc,

I added the devicetree list to this thread.
Please also have a look at the AI review:

https://sashiko.dev/#/patchset/20260318092215.23505-1-ciprianmarian.costea%40oss.nxp.com

Especially on patch#3.

I think we should split the main IRQ handler into 3 parts, message buff,
bus error and state change.

regards,
Marc
Thanks for pointing to the AI review.

It raises two concerns:

1. Duplicate event processing (can be addressed by splitting the handler
as you've suggested).

This is a pre-existing issue affecting S32G2 (NR_IRQ_3 with 4 IRQ lines
to the same handler) and MCF5441X (3 IRQ lines on the same handler).
I'll include this as a preparatory patch in the next version of the series.

2. Concurrent skb_irq_queue access (pre-existing, separate scope)

The __skb_queue_add_sort() calls on offload->skb_irq_queue are lockless.
When the mb and esr handlers run concurrently on different CPUs, both
can manipulate the list simultaneously.
This is a valid concern, but it's also pre-existing.

The fix requires changes in CAN core's rx-offload.c rather than in
flexcan, so I think it would be better handled in a separate series.

Would you agree ?

Best regards,
Ciprian


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help