On 7/7/24 8:47 PM, Thomas Gleixner wrote:
Marek!
Hello Thomas,
On Sat, Jul 06 2024 at 15:27, Marek Vasut wrote:
This is an RFC patch, I am looking for input on the approach taken here.
If the approach is sound, this patch would be split into proper patchset.
Various PCIe controllers that mux MSIs onto single IRQ line produce these
"IRQ%d: set affinity failed" warnings when entering suspend. This has been
discussed before [1] [2] and an example test case is included at the end
of this commit message.
Attempt to silence the warning by returning specific error code -EOPNOTSUPP
from the irqchip .irq_set_affinity callback, which skips printing the warning
in cpuhotplug.c . The -EOPNOTSUPP was chosen because it indicates exactly what
the problem is, it is not possible to set affinity of each MSI IRQ line to a
specific CPU due to hardware limitation.
Why does the irq_chip in question have an irq_set_affinity() callback in
the first place?
I believe originally (at least that's what's being discussed in the
linked threads) it was because the irqchip code didn't check whether
.irq_set_affinity was not NULL at all, so if it was missing, there would
be NULL pointer dereference.
Now this is checked and irq_do_set_affinity() returns -EINVAL, which
triggers the warning that is being silenced by this patch.
If you think this is better, I can:
- Tweak the cpuhotplug.c code to do some
if (chip && !chip->irq_set_affinity) return false;
- Remove all the .irq_set_affinity implementations from PCI drivers
which only return -EINVAL
Would that be better ?
--
Best regards,
Marek Vasut
