Re: [PATCH v4 03/48] irqchip/gic-v5: Set up gic_kvm_info on ACPI hosts

On Sat, 25 Jul 2026 at 11:06, Marc Zyngier <[email protected]> wrote:
>
> On Fri, 24 Jul 2026 12:19:20 +0100,
> [email protected] wrote:
> >
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [High] Failed ACPI GSI registration for maintenance IRQ due to missing GICv5 hardware IRQ type encoding.
> > --
>
> [...]
>
> > [Severity: High]
> > Does this fail to register the maintenance IRQ?
> >
> > acpi_register_gsi() passes the raw maint_irq directly into fwspec.param[0].
> > However, the GICv5 PPI domain select function expects the hardware IRQ type to
> > be encoded in the upper bits:
> >
> > drivers/irqchip/irq-gic-v5.c:gicv5_irq_ppi_domain_select() {
> >     ...
> >     if (is_fwnode_irqchip(fwspec->fwnode))
> >         hwirq_type = FIELD_GET(GICV5_HWIRQ_TYPE, fwspec->param[0]);
> >
> >     if (hwirq_type != GICV5_HWIRQ_TYPE_PPI)
> >         return 0;
> >     ...
> > }
> >
> > Because the raw MADT value doesn't have the GICV5_HWIRQ_TYPE_PPI bits set, the
> > mapping will be rejected. Should the GSI be encoded with the PPI type before
> > calling acpi_register_gsi()?
>
> Where is this coming from? I can't even find any public documentation
> for ACPI GICv5 support...
>
> Sascha?

I mentioned this reviewing another one of the patches in this series
[1]; I was planing to update the review-prompts once this series is
merged. That said, I am considering starting now, with the existing
GICv5 code and spec, but not include any of the code that is in _this_
series as part of the prompts until this series is merged. That might
be better, since it would make reviewing the next respin easier.

Cheers,
/fuad

[1] https://lore.kernel.org/all/CA+EHjTz0byw1LJDnqJGsPgOYz-pwyyY_u5S_44CbKGAfKnQkgQ@mail.gmail.com/

>
>         M.
>
> --
> Jazz isn't dead. It just smells funny.
>