Re: [PATCH 3/6] mips: Move IP30 timer to request_percpu_irq()

[Marc Zyngier <maz@kernel.org>]

On Thu, 11 Dec 2025 01:58:06 +0000,
Jinjie Ruan <ruanjinjie@huawei.com> wrote:
> 
> 
> 
> On 2025/12/10 16:22, Marc Zyngier wrote:
> > Teach the SGI IP30 timer about request_percpu_irq(), which ultimately
> > will allow for the removal of the antiquated setup_percpu_irq() API.
> > 
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/mips/include/asm/cevt-r4k.h |  1 -
> >  arch/mips/kernel/cevt-r4k.c      | 11 -----------
> >  arch/mips/sgi-ip30/ip30-timer.c  |  5 ++---
> >  3 files changed, 2 insertions(+), 15 deletions(-)
> > 
> > diff --git a/arch/mips/include/asm/cevt-r4k.h b/arch/mips/include/asm/cevt-r4k.h
> > index 2e13a038d2600..5229eb34f28a4 100644
> > --- a/arch/mips/include/asm/cevt-r4k.h
> > +++ b/arch/mips/include/asm/cevt-r4k.h
> > @@ -23,7 +23,6 @@ void mips_event_handler(struct clock_event_device *dev);
> >  int c0_compare_int_usable(void);
> >  irqreturn_t c0_compare_interrupt(int, void *);
> >  
> > -extern struct irqaction c0_compare_irqaction;
> >  extern int cp0_timer_irq_installed;
> >  
> >  #endif /* __ASM_CEVT_R4K_H */
> > diff --git a/arch/mips/kernel/cevt-r4k.c b/arch/mips/kernel/cevt-r4k.c
> > index 5f6e9e2ebbdbb..f58325f9bd2bc 100644
> > --- a/arch/mips/kernel/cevt-r4k.c
> > +++ b/arch/mips/kernel/cevt-r4k.c
> > @@ -159,17 +159,6 @@ irqreturn_t c0_compare_interrupt(int irq, void *dev_id)
> >  	return IRQ_NONE;
> >  }
> >  
> > -struct irqaction c0_compare_irqaction = {
> > -	.handler = c0_compare_interrupt,
> > -	/*
> > -	 * IRQF_SHARED: The timer interrupt may be shared with other interrupts
> > -	 * such as perf counter and FDC interrupts.
> > -	 */
> > -	.flags = IRQF_PERCPU | IRQF_TIMER | IRQF_SHARED,
> 
> The flags will add a "IRQF_NO_SUSPEND" when using request_percpu_irq(),
> is there any change?

I don't think this is a material change, given that power management
on an SGI Octane is simply non-existent.

In any case, this matches what we expect from per-CPU timers, and if
this box has different requirements, then we should discuss that
instead of treating as a special case that must be preserved.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.