[PATCH] rtc: mxc_v2: fix clk enable-count underflow warning in remove()

[PATCH] rtc: mxc_v2: fix clk enable-count underflow warning in remove()

[Cong Nguyen]

After probe, pdata->clk is left prepared but disabled -- every RTC
callback enables/disables it transiently around register access.
mxc_rtc_remove() calls clk_disable_unprepare(), which disables it
again and hits clk_core_disable()'s "already disabled" WARN().

Use plain clk_unprepare() instead, matching the probe-failure paths
which already do this correctly.

Fixes: 83c880f79e88 ("rtc: add mxc driver for i.MX53 SRTC")
Assisted-by: Claude:claude-opus-4
Signed-off-by: Cong Nguyen <congnt264@gmail.com>
---
 drivers/rtc/rtc-mxc_v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-mxc_v2.c b/drivers/rtc/rtc-mxc_v2.c
index a07acbbcfaeb..93dcf18abde2 100644
--- a/drivers/rtc/rtc-mxc_v2.c
+++ b/drivers/rtc/rtc-mxc_v2.c
@@ -365,7 +365,7 @@ static void mxc_rtc_remove(struct platform_device *pdev)
 {
 	struct mxc_rtc_data *pdata = platform_get_drvdata(pdev);
 
-	clk_disable_unprepare(pdata->clk);
+	clk_unprepare(pdata->clk);
 }
 
 static const struct of_device_id mxc_ids[] = {
-- 
2.25.1

Re: [PATCH] rtc: mxc_v2: fix clk enable-count underflow warning in remove()

[sashiko-bot]

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

Pre-existing issues:
- [High] Missing cleanup for dev_pm_set_wake_irq() leading to a memory leak and dangling wake IRQ on probe failure or device removal.
- [High] Premature unprepare of the clock in remove() causes a use-after-disable race with devres-managed resources.
--

commit 3311fdd80d87e5108fcbeddc8974c58c3e0da127
Author: Cong Nguyen <congnt264@gmail.com>

rtc: mxc_v2: fix clk enable-count underflow warning in remove()

After probe, the clock is left prepared but disabled, so calling
clk_disable_unprepare() in remove() hits an already disabled warning.
This commit changes it to clk_unprepare() to match the probe-failure paths.

> diff --git a/drivers/rtc/rtc-mxc_v2.c b/drivers/rtc/rtc-mxc_v2.c
> index 570f27af4732e..ab2ab61017f57 100644
> --- a/drivers/rtc/rtc-mxc_v2.c
> +++ b/drivers/rtc/rtc-mxc_v2.c
> @@ -366,7 +366,7 @@ static void mxc_rtc_remove(struct platform_device *pdev)
>  {
>  	struct mxc_rtc_data *pdata = platform_get_drvdata(pdev);
>  
> -	clk_disable_unprepare(pdata->clk);
> +	clk_unprepare(pdata->clk);

[Severity: High]
This is a pre-existing issue, but does unpreparing the clock here cause a
use-after-disable race with devres-managed resources?

The IRQ handler is registered via devm_request_irq() in mxc_rtc_probe(),
which means it stays active after mxc_rtc_remove() returns. If an RTC
interrupt fires after the clock is unprepared (for example, during the
devres cleanup window), the interrupt handler mxc_rtc_interrupt() calls
clk_enable() on an unprepared clock:

drivers/rtc/rtc-mxc_v2.c:mxc_rtc_interrupt() {
    ...
    if (clk_enable(pdata->clk)) {
        spin_unlock(&pdata->lock);
        return IRQ_NONE;
    }
    ...
}

This can trigger a kernel warning for enabling an unprepared clock, and
cause the interrupt handler to return IRQ_NONE without clearing the hardware
status, which could lead to an interrupt storm.

[Severity: High]
This is a pre-existing issue, but is there a missing cleanup for the wake IRQ
when removing the device?

The unmanaged wake IRQ is allocated and attached in mxc_rtc_probe():

drivers/rtc/rtc-mxc_v2.c:mxc_rtc_probe() {
    ...
    ret = dev_pm_set_wake_irq(&pdev->dev, pdata->irq);
    ...
}

However, mxc_rtc_remove() completes without clearing the wake IRQ. This can
lead to a memory leak and leave a dangling wake IRQ on driver unbind.
Subsequent probe attempts could hit an -EEXIST error and trigger a warning
if probe is retried after a failure or during a rebind.

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914132505.2356970-1-congnt264@gmail.com?part=1