Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Vincent Mailhol <mailhol@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Frank Li <Frank.Li@nxp.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	linux-can@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, imx@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	NXP S32 Linux Team <s32@nxp.com>,
	Christophe Lizzi <clizzi@redhat.com>,
	Alberto Ruiz <aruizrui@redhat.com>,
	Enric Balletbo <eballetb@redhat.com>,
	Eric Chanudet <echanude@redhat.com>
Subject: Re: [PATCH v3 1/6] can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
Date: Tue, 24 Mar 2026 14:30:50 +0200	[thread overview]
Message-ID: <024316c6-aa33-4561-889c-abd9eeb9d83f@oss.nxp.com> (raw)
In-Reply-To: <20260324-psychedelic-idealistic-dormouse-95b03c-mkl@pengutronix.de>

On 3/24/2026 1:56 PM, Marc Kleine-Budde wrote:
> On 23.03.2026 14:58:22, Ciprian Costea wrote:
>> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>>
>> On platforms with multiple IRQ lines (S32G2, MCF5441X), all lines are
>> registered to the same flexcan_irq() handler. Since these are distinct IRQ
>> numbers, they can be dispatched concurrently on different CPUs. Both
>> instances then read the same iflag and ESR registers unconditionally,
>> leading to duplicate frame processing.
>>
>> Fix this by splitting the monolithic handler into focused parts:
>> - flexcan_do_mb(): processes mailbox events
>> - flexcan_do_state(): processes device state change events
>> - flexcan_do_berr(): processes bus error events
>>
>> Introduce dedicated IRQ handlers for multi-IRQ platforms:
>> - flexcan_irq_mb(): mailbox-only, used for mb-0, mb-1 IRQ lines
>> - flexcan_irq_boff(): state-change-only, used for boff/state IRQ line
>> - flexcan_irq_berr(): bus-error-only, used for berr IRQ line
>>
>> The combined flexcan_irq() handler is preserved for single-IRQ
>> platforms with no functional change.
> 
> Thanks for implementing this.
> 
> Can you take care of the S32G2 which has 2 mailbox IRQs, too? Please in
> a separate patch.
> 
> My idea was to take the "irq" argument of the IRQ handler and the quirks
> and figure out if you are the first or second mailbox IRQ handler.
> 
> Convert these
> 
> | struct flexcan_priv {
> | [...]
> | 	u64 rx_mask;
> | 	u64 tx_mask;
> | [...]
> | }
> 
> into a struct and put an array of 2 of these structs into "struct
> flexcan_priv". Use correct mask array depending on IRQ handler.
> 
> regards,
> Marc
> 
> --
> Pengutronix e.K.                 | Marc Kleine-Budde          |
> Embedded Linux                   | https://www.pengutronix.de |
> Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Hello Marc,

Thanks for your review.
I'll add a separate patch implementing per-MB-IRQ mask handling (needed
by S32G2) in V4. And thanks for the implementation suggestion. I'll take
it into account.

Now, unrelated to the per-MB-IRQ refactor, one thing I noticed during 
the IRQ handlers split: dev->stats counters (e.g. rx_fifo_errors) can
be incremented concurrently from different IRQ handlers on different CPUs.

That said, these are just diagnostic counters and lost increments
should be benign. Do you think this warrants any synchronization/locking 
mechanism, or is the current behavior acceptable?

Regards,
Ciprian



  reply	other threads:[~2026-03-24 12:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-23 13:58 [PATCH v3 0/6] can: flexcan: Add NXP S32N79 SoC support Ciprian Costea
2026-03-23 13:58 ` [PATCH v3 1/6] can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms Ciprian Costea
2026-03-24 11:56   ` Marc Kleine-Budde
2026-03-24 12:30     ` Ciprian Marian Costea [this message]
2026-03-24 13:44       ` Marc Kleine-Budde
2026-03-23 13:58 ` [PATCH v3 2/6] dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support Ciprian Costea
2026-03-23 19:35   ` Conor Dooley
2026-03-23 13:58 ` [PATCH v3 3/6] can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk Ciprian Costea
2026-03-23 13:58 ` [PATCH v3 4/6] can: flexcan: add NXP S32N79 SoC support Ciprian Costea
2026-03-23 13:58 ` [PATCH v3 5/6] arm64: dts: s32n79: add FlexCAN nodes Ciprian Costea
2026-03-23 13:58 ` [PATCH v3 6/6] arm64: dts: s32n79: enable FlexCAN devices Ciprian Costea
2026-03-24 11:58 ` [PATCH v3 0/6] can: flexcan: Add NXP S32N79 SoC support Marc Kleine-Budde
2026-03-24 12:18   ` Ciprian Marian Costea
2026-03-24 13:46 ` Marc Kleine-Budde
2026-03-25 12:45   ` Ciprian Marian Costea

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=024316c6-aa33-4561-889c-abd9eeb9d83f@oss.nxp.com \
    --to=ciprianmarian.costea@oss.nxp.com \
    --cc=Frank.Li@nxp.com \
    --cc=aruizrui@redhat.com \
    --cc=clizzi@redhat.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=eballetb@redhat.com \
    --cc=echanude@redhat.com \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=s32@nxp.com \
    /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