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

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-05-05 13:02:16 [+0100], Maciej W. Rozycki wrote:
> > 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.

Why? There is a mask_irq() in the ONESHOT case.

>  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.

If there is a chain and you have multiple controllers then the different
low-lever handler might be the way to go.
But IRQF_ONESHOT servers a different purpose. If you use request_irq()
then there is no threaded-handler and as such IRQF_ONESHOT does nothing
except avoiding force-threading the primary handler. But that is a
side-effet. If you want to avoid to force-threading the irq-handler then
IRQF_NO_THREAD would be the right flag.

>  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.

But there is a plain request_irq() so the handler is invoked directly in
hardirq context with disabled interrupts. In forced-threaded context,
such as on PREEMPT_RT, the IRQF_ONESHOT is added.

>   Maciej

Sebastian