Re: [PATCH v3] net: mvneta: re-enable percpu interrupt on resume

[Zhou, Yun]

On 6/18/2026 8:51 PM, Sebastian Andrzej Siewior wrote:
> On 2026-06-18 18:43:51 [+0800], Yun Zhou wrote:
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -5907,6 +5907,9 @@ static int mvneta_resume(struct device *device)
> >        rtnl_unlock();
> >        mvneta_set_rx_mode(dev);
> >
> > +     if (!pp->neta_armada3700)
> > +             on_each_cpu(mvneta_percpu_enable, pp, true);
> > +
> >        return 0;
> >   }
> >   #endif
>
> This does not look symmetrical. I wouldn't mind if mvneta_suspend()
> would have the matching disable but this isn't the case.
> But if the thread is idle then you have one enable too many, don't you?
> Well you have the NAPI callback which does disable on the local CPU and
> this resume which enables it on every CPU. So this does not look right.

The enable in resume is intentionally unconditional and idempotent
(writing MPIC_INT_CLEAR_MASK on an already unmasked IRQ is a no-op).

> The interesting question is what happens to the enable_percpu_irq() from
> the mvneta_poll(). Is it lost? And if so, how/ why?

The enable_percpu_irq() from mvneta_poll is not "lost" — it never
gets a chance to execute. The sequence is:

1. mvneta_percpu_isr: disable_percpu_irq() + napi_schedule()
2. PM freezes kthreads (on PREEMPT_RT, softirq runs in kthread)
3. NAPI poll cannot run → enable_percpu_irq() is never called
4. mvneta_stop_dev → napi_disable(): cancels the scheduled poll
    but does NOT execute the completion path (no enable_percpu_irq)
5. Resume → napi_enable(): resets NAPI state but MPIC stays masked

The unconditional enable in resume covers this case. When NAPI was
idle at suspend time, the extra enable is harmless.

BR,
Yun