RE: [PATCH v2 3/3] x86/irq, iommu/amd, PCI: Drop redundant irq_retrigger inits

[Thomas Gleixner <tglx@kernel.org>]

On Thu, Sep 10 2026 at 18:51, Michael Kelley wrote:
> From: Thomas Gleixner <tglx@kernel.org> Sent: Wednesday, September 9, 2026 3:24 AM
>> In any case 'irqd' in msi_set_affinity() will always point to the vector
>> domain and therefore the exiting code is correct and can't be changed to
>> retrigger hierarchy as that would see irqd->parent == NULL and do
>> nothing. Neither will adding a conditional there do anything useful
>> because the vector domain always has the retrigger callback set.
>> 
>
> Hmmm. I've been staring at the code to try to understand it all,
> and I'm not seeing that 'irqd' in msi_set_affinity() always points to
> the VECTOR domain.

You are right and I'm an idiot.

My brain was already melted from debating memory ordering issues, then I
ended up completely confusing the set affinity and the retrigger
logic. Let me try again.

What I completely messed up was that the MSI core sets by default
msi_domain_set_affinity(), which uses the parent domain, but only if the
template/chp does not provide an .irq_set_affinity() callback.

Which is not true when remapping is off because x86_init_dev_msi_info()
sets it to msi_set_affinity(). Duh!

So the change is _not_ broken.

Though my argument that retrigger has to happen at the vector level
still stands because the outermost chip is in fire and forget mode and
to the best of my knowledge none of them have a retrigger at the
interrupt chip level. And from a design perspective there won't be any
in the future (famous last words).

Devices might have a way to retrigger at the device level, but that's
not reachable from the interrupt chip.

So both places fixup_irq() and msi_set_affinity() can use retrigger
hierarchy safely without the conditional checking the outermost domain
chip.

Thanks,

        tglx