[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <176972706654.2495410.11469395258189630227.tip-bot2@tip-bot2>
Date: Thu, 29 Jan 2026 22:51:06 -0000
From: "tip-bot2 for Thomas Gleixner" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: Jon Hunter <jonathanh@...dia.com>, Thomas Gleixner <tglx@...nel.org>,
x86@...nel.org, linux-kernel@...r.kernel.org
Subject: [tip: irq/msi] genirq/redirect: Prevent writing MSI message on
affinity change
The following commit has been merged into the irq/msi branch of tip:
Commit-ID: 37f9d5026cd78fbe80a124edbbadab382b26545f
Gitweb: https://git.kernel.org/tip/37f9d5026cd78fbe80a124edbbadab382b26545f
Author: Thomas Gleixner <tglx@...nel.org>
AuthorDate: Tue, 27 Jan 2026 22:30:16 +01:00
Committer: Thomas Gleixner <tglx@...nel.org>
CommitterDate: Thu, 29 Jan 2026 23:49:55 +01:00
genirq/redirect: Prevent writing MSI message on affinity change
The interrupts which are handled by the redirection infrastructure provide
a irq_set_affinity() callback, which solely determines the target CPU for
redirection via irq_work and und updates the effective affinity mask.
Contrary to regular MSI interrupts this affinity setting does not change
the underlying interrupt message as the message is only created at setup
time to deliver to the demultiplexing interrupt.
Therefore the message write in msi_domain_set_affinity() is a pointless
exercise. In principle the write is harmless, but a Tegra system exposes a
full system hang during suspend due to that write.
It's unclear why the check for the PCI device state PCI_D0 in
pci_msi_domain_write_msg(), which prevents the actual hardware access if
a device is in powered down state, fails on this particular system, but
that's a different problem which needs to be investigated by the Tegra
experts.
The irq_set_affinity() callback can advise msi_domain_set_affinity() not to
write the MSI message by returning IRQ_SET_MASK_OK_DONE instead of
IRQ_SET_MASK_OK. Do exactly that.
Just to make it clear again:
This is not a correctness issue of the redirection code as returning
IRQ_SET_MASK_OK in that context is completely correct. From the core
code point of view this is solely a optimization to avoid an redundant
hardware write.
As a byproduct it papers over the underlying problem on the Tegra platform,
which fails to put the PCIe device[s] out of PCI_D0 despite the fact that
the devices and busses have been shut down. The redirect infrastructure
just unearthed the underlying issue, which is prone to happen in quite some
other code paths which use the PCI_D0 check to prevent hardware access to
powered down devices.
This therefore has neither a 'Fixes:' nor a 'Closes:' tag associated as the
underlying problem, which is outside the scope of the interrupt code, is
still unresolved.
Reported-by: Jon Hunter <jonathanh@...dia.com>
Signed-off-by: Thomas Gleixner <tglx@...nel.org>
Tested-by: Jon Hunter <jonathanh@...dia.com>
Link: https://lore.kernel.org/all/4e5b349c-6599-4871-9e3b-e10352ae0ca0@nvidia.com
Link: https://patch.msgid.link/87tsw6aglz.ffs@tglx
---
kernel/irq/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 35bc17b..ccdc47a 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1495,7 +1495,7 @@ int irq_chip_redirect_set_affinity(struct irq_data *data, const struct cpumask *
WRITE_ONCE(redir->target_cpu, cpumask_first(dest));
irq_data_update_effective_affinity(data, dest);
- return IRQ_SET_MASK_OK;
+ return IRQ_SET_MASK_OK_DONE;
}
EXPORT_SYMBOL_GPL(irq_chip_redirect_set_affinity);
#endif
Powered by blists - more mailing lists