Re: [PATCH] genirq/PM: Re-enable chained interrupts after hibernation

[Zhu Ling]

Hi Thomas,

Thank you for the review. I am withdrawing the previous genirq/PM
proposal. Please do not apply it: forcing chained IRQs through generic
resume treats the symptom rather than restoring controller state.

I have since reproduced the failure on the Phytium E2000Q platform
using upstream base 17bb0e2f6c8043f70a693a5f3797471cbed354c8.
GPIOLIB is disabled and no vendor GPIO driver is involved. An independent
module registers either an ordinary or chained handler on an idle
GICv3 SPI (INTID 189) and injects a real GIC pending event before and
after hibernation. It has no PM callbacks or automatic recovery.

On separate fresh boots, the ordinary IRQ delivers both injections.
The chained IRQ delivers only the first. After real S4, its descriptor
still reports started=1, disabled=0 and sw_masked=0, but the hardware
enable bit is clear and the second event remains pending. An explicit
unmask delivers that queued event without another injection or handler
reinstallation.

A GICv3-side SPI context save/restore revision passes the same test
in both modes: hits=2, injected=2, unexpected=0 and rescued=0. Each
mode was tested for one real S4 cycle on a fresh boot, with CPU0,
disk=shutdown and pm_test=none. No introducing commit is claimed.

The test kernels contain a separate 8-line USB host enablement, but
the unpatched test leaves the IRQ/GIC/PM paths unchanged. The test
module sets the out-of-tree taint bit; both conditions are disclosed
in the new cover letter.

I will send v2 as a separate thread, linking this discussion. It
preserves SPI distributor configuration in GICv3 and does not change
genirq policy. It is not a claim of complete GICv3/ITS S4 support.

Thanks,
Zhu Ling