Re: [PATCH] regulator: pf1550: fix which regulator is notified

[Donggeun Yoo <donggeunyoo.kernel@gmail.com>]

On Fri, Sep 04, 2026 at 11:10:38AM +0000, sashiko-bot@kernel.org wrote:
> This is a pre-existing issue, but returning IRQ_HANDLED when the driver
> completely fails to recognize the interrupt defeats the kernel's spurious
> interrupt detection.
>
> If the PMIC continuously asserts an unhandled fault, could the parent
> regmap-irq thread loop endlessly resulting in an interrupt storm and CPU
> lockup? Should this return IRQ_NONE instead?

The branch is not reachable.

probe() requests the handler for the eleven interrupts returned by
platform_get_irq(pdev, 0..PF1550_REGULATOR_IRQ_NR-1), without IRQF_SHARED,
and the lookup loop rebuilds that list with the same calls. The cell has no
.of_compatible, so platform_get_irq() returns the number mfd_add_device()
stored in the resource once, through irq_create_mapping(). Both loops see
the same numbers, so irq_type is always in range.

An interrupt the driver has no entry for cannot reach the handler either.
regmap_irq_thread() dispatches only the bits registered in the irq chip, so
there is nothing for the described storm to come from.

The point about handle_nested_irq() feeding note_interrupt() is right in
general, it just does not apply here.

Thanks,
Donggeun