Re: [PATCH v4] ACPI: AGDI: Add interrupt signaling mode support

[Lorenzo Pieralisi <lpieralisi@kernel.org>]

[+cc Thomas, Marc]

On Tue, Nov 11, 2025 at 11:42:37PM -0500, Charles Mirabile wrote:
> Hi All—
> 
> On Mon, Nov 10, 2025 at 07:38:17AM +0000, Kazuhiro Abe (Fujitsu) wrote:
> > Hi Will,
> > 
> > > Hi Will,
> > > 
> > > > [You don't often get email from will@kernel.org. Learn why this is
> > > > important at https://aka.ms/LearnAboutSenderIdentification ]
> > > >
> > > > On Mon, Oct 20, 2025 at 09:23:05PM +0800, Hanjun Guo wrote:
> > > > > On 2025/10/17 15:39, Kazuhiro Abe wrote:
> > > > > > AGDI has two types of signaling modes: SDEI and interrupt.
> > > > > > Currently, the AGDI driver only supports SDEI.
> > > > > > Therefore, add support for interrupt signaling mode The interrupt
> > > > > > vector is retrieved from the AGDI table, and call panic function
> > > > > > when an interrupt occurs.
> > > > > >
> > > > > > Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
> > > > > > Signed-off-by: Kazuhiro Abe <fj1078ii@aa.jp.fujitsu.com>
> > > > > > ---
> > > > > > Hanjun, I have addressed all your comments.
> > > > > > Please review them.
> > > > > >
> > > > > > v3->v4
> > > > > >   - Add a comment to the flags member.
> > > > > >   - Fix agdi_interrupt_probe.
> > > > > >   - Fix agdi_interrupt_remove.
> > > > > >   - Add space in struct initializsation.
> > > > > >   - Delete curly braces.
> > > > >
> > > > > Looks good to me,
> > > > >
> > > > > Acked-by: Hanjun Guo <guohanjun@huawei.com>
> > > >
> > > > I wasn't cc'd on the original patch but I couldn't figure out why it
> > > > uses IRQF_NO_AUTOEN when requesting the irq given that the first thing
> > > > it does is enable it.
> > > 
> > > I misunderstood the usage of request_irq and enable_irq.
> > > Since there's no need to separate them, I will remove IRQF_NO_AUTOEN and the
> > > enable_irq call, and send v5.
> > 
> > I found out when calling request_nmi, removing IRQF_NO_AUTOEN results in an error (-EINVAL).
> > Therefore, I would like to keep IRQF_NO_AUTOEN specified.
> > If you have any comments on this version, please let me know.
> 
> Could it be that this is just a bug in `request_nmi`? I see the following:
> 
> if (!desc || (irq_settings_can_autoenable(desc) &&
>     !(irqflags & IRQF_NO_AUTOEN)) ||
>     !irq_settings_can_request(desc) ||
>     WARN_ON(irq_settings_is_per_cpu_devid(desc)) ||
>     !irq_supports_nmi(desc))
> 	return -EINVAL;
> 
> Perhaps there is just a missing `!` before `irq_settings_can_autoenable`.
> 
> As far as I can tell it has always been wrong - git blame points me to the
> original commit where that code was introduced:
> 
> b525903c254da ("genirq: Provide basic NMI management for interrupt lines")

I don't think that's the right rationale (and I can't claim to understand
it fully either - that's why I added Thomas/Marc in CC).

As per b525903c254da - IIUC NMI must not be autoenable-capable -
enable/disable must be done using enable_nmi/disable_nmi_nosync explicitly.

cbe16f35bee6 ("genirq: Add IRQF_NO_AUTOEN for request_irq/nmi()")
added the logic checking the IRQF_NO_AUTOEN flag to request_nmi().

Now, AFAICS irq_settings_can_autoenable(desc) returns true in this
specific case - the IRQ is a GICv3 SPI.

First question is - before commit cbe16f35bee6, how request_nmi() could
have possibly succeeded - irq_settings_can_autoenable() would return
true and request_nmi() would have failed.

Come cbe16f35bee6:

if (!desc || (irq_settings_can_autoenable(desc) && !(irqflags & IRQF_NO_AUTOEN)) ||
	!irq_settings_can_request(desc) ||
	WARN_ON(irq_settings_is_per_cpu_devid(desc)) ||
	!irq_supports_nmi(desc))
		return -EINVAL;

Now the check passes _if_ you pass in irqflags IRQF_NO_AUTOEN.

I agree with Will that's a bit counterintuitive - maybe we can force
the irqdesc to be NOAUTOEN in request_nmi() directly ?

Thomas and Marc know better so that's where I stop.

Thanks,
Lorenzo

> I looked and the only two callers are using `IRQF_NO_AUTOEN` so I guess it
> just hasn't been noticed yet.
> 
> Happy to send a patch to fix it.
> 
> > 
> > Best Regards,
> > Kazuhiro Abe
> > 
> > > 
> > > Best Regards,
> > > Kazuhiro Abe
> > > 
> > > >
> > > > Will
> 
> Best—Charlie
>