rtc: mxc_v2: fix clk enable-count underflow warning in remove()
Subsystems (2)
PATCH 1/1 rtc: mxc_v2: fix clk enable-count underflow warning in remove()
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.
--- drivers/rtc/rtc-mxc_v2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/rtc/rtc-mxc_v2.c +1 -1
@@ -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[] = {
Signature · 1 line
2.25.1
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
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 <[email protected]>
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.
drivers/rtc/rtc-mxc_v2.c static void mxc_rtc_remove(struct platform_device *pdev) · line 369
Quoted 10 lines
drivers/rtc/rtc-mxc_v2.c +1
-1@@ -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.
Quoted 1 line
drivers/rtc/rtc-mxc_v2.c +0
-0}
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1