Re: [PATCH AUTOSEL 6.18-6.12] rtc: mv: add suspend/resume support for wakeup

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] The driver unconditionally calls disable_irq_wake() in mv_rtc_resume() if device_may_wakeup() is true, ignoring whether enable_irq_wake() actually succeeded during suspend. On platforms with irqchips that do not support wake configuration, this causes a WARN(1) splat on resume.

Pre-existing issues:
- [High] The probe function silently disables alarm functionality if platform_get_irq() returns an error, failing to handle -EPROBE_DEFER correctly.
- [High] The device clock is disabled in `mv_rtc_remove()` while the shared interrupt is still registered, which could cause a bus error and kernel panic if the interrupt fires.
--

commit a94ce5838cf02b58cbaaa54595d3a6090ffe754c
Author: Xue Lei <Xue.Lei@windriver.com>

rtc: mv: add suspend/resume support for wakeup

Add PM suspend/resume callbacks to enable/disable IRQ wake for the
RTC alarm interrupt. This allows the RTC alarm to wake the system
from STR (e.g. via rtcwake -m mem -s N).

Link: https://patch.msgid.link/20260611023350.1370881-1-Xue.Lei@windriver.com

> diff --git a/drivers/rtc/rtc-mv.c b/drivers/rtc/rtc-mv.c
> index c27ad626d09fc..f88976fd6d5da 100644
> --- a/drivers/rtc/rtc-mv.c
> +++ b/drivers/rtc/rtc-mv.c
[ ... ]
> @@ -301,6 +301,28 @@ static const struct of_device_id rtc_mv_of_match_table[] = {
[ ... ]
> +#ifdef CONFIG_PM_SLEEP
> +static int mv_rtc_suspend(struct device *dev)
> +{
> +	struct rtc_plat_data *pdata = dev_get_drvdata(dev);
> +
> +	if (device_may_wakeup(dev) && pdata->irq >= 0)
> +		enable_irq_wake(pdata->irq);
> +	return 0;
> +}
> +
> +static int mv_rtc_resume(struct device *dev)
> +{
> +	struct rtc_plat_data *pdata = dev_get_drvdata(dev);
> +
> +	if (device_may_wakeup(dev) && pdata->irq >= 0)
> +		disable_irq_wake(pdata->irq);

[Severity: High]
Does this code trigger an unbalanced wake disable warning on resume if
enable_irq_wake() failed during suspend?

In mv_rtc_suspend(), the return value of enable_irq_wake() is ignored. On
Kirkwood and Dove platforms, the orion-intc irqchip does not support wake
configuration, so enable_irq_wake() fails and returns -ENXIO without
incrementing the IRQ's wake_depth.

During system resume, disable_irq_wake() will be called unconditionally,
which decrements the wake_depth from 0 and triggers a warning splat.

> +	return 0;
> +}
> +#endif
[ ... ]

While reviewing this driver, I noticed a few pre-existing issues:

drivers/rtc/rtc-mv.c:mv_rtc_probe() {
[ ... ]
	pdata->irq = platform_get_irq(pdev, 0);
[ ... ]
	if (pdata->irq >= 0)
		device_init_wakeup(&pdev->dev, true);
	else
		clear_bit(RTC_FEATURE_ALARM, pdata->rtc->features);
[ ... ]
}

[Severity: High]
This is a pre-existing issue, but does this code permanently disable the
alarm functionality if the IRQ probe is deferred?

If the interrupt controller is not yet ready during mv_rtc_probe(),
platform_get_irq() returns -EPROBE_DEFER. Because this value is negative,
the code skips IRQ setup and executes the clear_bit() path, successfully
registering the RTC device without the alarm instead of properly deferring
the probe.

drivers/rtc/rtc-mv.c:mv_rtc_remove() {
[ ... ]
	if (!IS_ERR(pdata->clk))
		clk_disable_unprepare(pdata->clk);
}

[Severity: High]
This is a pre-existing issue, but can this code cause a bus fault if a
shared interrupt fires while the module is being removed?

The device clock is disabled here, but the interrupt is requested using
devm_request_irq() with IRQF_SHARED. Because the IRQ is devres-managed, it
is not freed until devres_release_all() runs after mv_rtc_remove() completes.

If another device on the same shared IRQ line triggers an interrupt during
this window, mv_rtc_interrupt() will execute:

drivers/rtc/rtc-mv.c:mv_rtc_interrupt() {
	/* alarm irq? */
	if (!readl(ioaddr + RTC_ALARM_INTERRUPT_CASUE_REG_OFFS))
[ ... ]
}

Attempting to read from the device registers while the clock is disabled
could trigger a synchronous external abort and a kernel panic.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-454-sashal@kernel.org?part=1