Re: [PATCH v2] net: mvneta: free/request IRQ across suspend/resume

[Zhou, Yun]

On 6/17/26 20:49, Maxime Chevallier wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> Hi,
>
> On 6/17/26 11:20, Yun Zhou wrote:
> > On PREEMPT_RT, the mvneta IRQ handler is force-threaded. Under high
> > network traffic, the IRQ can enter suspend with desc->depth == 1
> > (masked by the oneshot mechanism between handler invocations).
> >
> > During suspend, the kernel increments depth to 2 and masks the
> > interrupt at the MPIC level (clearing the SRC_CTL CPU routing bit,
> > due to IRQCHIP_MASK_ON_SUSPEND). On resume, depth is decremented
> > back to 1, but since it does not reach 0, the unmask is never
> > called. The MPIC CPU routing remains cleared, permanently disabling
> > interrupt delivery.
> >
> > Fix by freeing the IRQ in suspend and re-requesting it in resume.
> > This ensures a clean IRQ state (depth=0, proper hardware routing)
> > on every resume cycle, regardless of the pre-suspend depth. This
> > follows the approach used by other drivers (e.g. igb).
> This description makes it sound like it's not really a mvneta problem,
> but rather a broader effect from  preempt-rt / irq management / suspend
> interactions.
>
> Is this the expected way to deal with that ?
You were right to question this. After deeper investigation, I found
that the original analysis was incorrect.

The real root cause is entirely within the mvneta driver:

mvneta_percpu_isr() calls disable_percpu_irq() to mask the MPIC percpu
IRQ before scheduling NAPI. The corresponding enable_percpu_irq() is
called in napi_complete_done(). If suspend occurs during active NAPI
polling (between disable and enable), the MPIC percpu IRQ remains
masked after resume — mvneta_start_dev() only restores the NIC-level
INTR_NEW_MASK register, not the irqchip-level per-CPU mask.

The fix is a one-liner: call on_each_cpu(mvneta_percpu_enable) in the
resume path to ensure the MPIC percpu IRQ is unmasked. I will send a
v3 with the correct fix and updated description.

The previous free_irq/request_irq approach happened to work as a
side-effect (request_percpu_irq → enable_percpu_irq restores the mask),
but it was fixing the symptom rather than the actual cause.

Thank you very much for your rigorous review,
Yun