Re: [PATCH net-next v2] declance: Remove IRQF_ONESHOT

Maciej W. Rozycki
2026-05-05T12:02:23Z

On Tue, 5 May 2026, Sebastian Andrzej Siewior wrote:

> > No reply, but I've gone through irq_setup_forced_threading() now and my
> > inference was indeed correct, and the handler does need to be installed
> > with IRQF_NO_THREAD. I'll send corrective patches shortly.
>
> Sorry. I missed that previous email.
> IRQF_NO_THREAD will not force-thread the interrupt handler so it will
> run with interrupts disabled.

That's one clear option I've identified and given that the handler
amounts to a printk() call it may well be the path of least resistance
solution.

> With force-threading enabled, the interrupt handler is masked in the
> IRQ-chip until after the threaded-handler run. See the cond_unmask_irq()
> in handle_level_irq() or the mask_irq() & cond_unmask_eoi_irq() in
> handle_fasteoi_ack_irq(). That means the hw-IRQ is done, the thread is
> running with interrupts enabled but the hw-IRQ will not trigger again.
> The cited commit 5a4a4ad851dd8 ("MIPS: Mark cascade and low level
> interrupts IRQF_NO_THREAD") is different as it acts on cascading
> interrupts which is not what we have here.

Not with the current handle_fasteoi_irq() handler.

And actually not with handle_fasteoi_ack_irq() either, which doesn't call
mask_irq() unless IRQF_ONESHOT has been requested (but ->irq_ack() could
be repurposed to do masking), however handle_fasteoi_mask_irq() seems a
matching candidate. To use that handler the platform would have to select
IRQ_DOMAIN_HIERARCHY and IRQ_FASTEOI_HIERARCHY_HANDLERS, although none of
the stuff beyond just handle_fasteoi_mask_irq() appears relevant, so it
seems like a waste of memory. Note that the handlers are much more recent
than the driver and back in the time IRQF_ONESHOT seemed a reasonable
approach.

The handle_level_irq() handler is irrelevant, because we do need to issue
the EOI for deassertion.

> If you request a threaded interrupt you must either provide two handler
> and the primary must mask the interrupt so it does not fire again or you
> pass a flag such as IRQF_ONESHOT and which point the IRQ subsystem will
> mask the IRQ within the irqchip so it does not fire again.

Well, yes, but you've just removed the flag from this driver, so either
the flag has to reinstated or the driver adjusted differently for the
threaded case to be handled correctly.

Maciej