Re: [PATCH v5 10/17] rtc: rzn1: Replace remove callback with devm_add_action_or_reset()

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Hardware interrupts are disabled after the IRQ handlers are freed during driver unbind, creating a window for spurious, unhandled interrupts.
--

--- Patch [10]: [PATCH v5 10/17] rtc: rzn1: Replace remove callback with devm_add_action_or_reset() ---
commit 473179016e2cef4b0d0185760b5e14362f0eadc1
Author: Lad Prabhakar <[email protected]>

rtc: rzn1: Replace remove callback with devm_add_action_or_reset()

This patch simplifies the driver teardown by replacing the explicit remove
callback and probe error paths with a managed cleanup action. It registers
rzn1_rtc_disable_hardware via devm_add_action_or_reset.

> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index 6a434cb418cd0..02d720e95a7f9 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
> @@ -421,18 +432,19 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
>  	if (ret < 0)
>  		return ret;
>  
> +	ret = devm_add_action_or_reset(&pdev->dev, rzn1_rtc_disable_hardware, &pdev->dev);
> +	if (ret)
> +		return ret;
> +

[Severity: High]
Since devres executes teardown actions in LIFO order, will registering the
hardware disable action here early in rzn1_rtc_probe cause it to run last
during driver unbind?

[ ... ]

> @@ -468,14 +480,12 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
>  	ret = devm_request_irq(&pdev->dev, irq, rzn1_rtc_alarm_irq, 0, "RZN1 RTC Alarm", rtc);
>  	if (ret) {
>  		dev_err(&pdev->dev, "RTC alarm interrupt not available\n");
> -		goto dis_runtime_pm;
> +		return ret;
>  	}

[Severity: High]
If devm_request_irq is called after the hardware disable action is
registered, won't the IRQ handlers be freed before the hardware is disabled
during teardown?

If an RTC alarm or 1-second interrupt is active when the driver unbinds,
could an interrupt fire in the devres teardown window where the handler is
gone but the hardware is still active? This might trigger the generic IRQ
subsystem's spurious interrupt detector, which could permanently disable the
IRQ line.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=10