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

[Ciprian Marian Costea]

On 3/19/2026 1:56 PM, Marc Kleine-Budde wrote:
> On 19.03.2026 10:40:27, Ciprian Costea wrote:
> > From: Ciprian Marian Costea <ciprianmarian.costea@xxxxxxxxxxx>
> >
> > 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