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

[Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>]

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@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