Re: [PATCH] rtc: rtc-cadence: fix clock cleanup ordering

[Christophe JAILLET]

Le 18/08/2026 à 14:41, Jiawen Liu a écrit :
> From: jiawen <1298662399@xxxxxx>
>
> The probe function enables the peripheral clock (pclk) before the
> reference clock (ref_clk), and its error path disables ref_clk before
> pclk. However, the remove function disables pclk before ref_clk, which
> is the reverse order. This asymmetric teardown can leave the clock
> framework in an inconsistent state and violates the expected lifecycle
> balance. Fix the remove function to disable ref_clk first, then pclk,
> matching the probe enable order and the error path cleanup order.
>
> Signed-off-by: jiawen <1298662399@xxxxxx>
> ---
> diff --git a/drivers/rtc/rtc-cadence.c b/drivers/rtc/rtc-cadence.c
> --- a/drivers/rtc/rtc-cadence.c
> +++ b/drivers/rtc/rtc-cadence.c
> @@ -361,8 +361,8 @@
>   	cdns_rtc_alarm_irq_enable(&pdev->dev, 0);
>   	device_init_wakeup(&pdev->dev, false);
>   
> +	clk_disable_unprepare(crtc->ref_clk);
>   	clk_disable_unprepare(crtc->pclk);
> -	clk_disable_unprepare(crtc->ref_clk);
>   }
>   
>   #ifdef CONFIG_PM_SLEEP

Hi,
you should use ./scripts/get_maintainer.pl to identify to who the patch 
should be sent. A pmatch only sent to linux-kernel@... will be taken by 
no-one.

Personally, I use "./scripts/get_maintainer.pl --nogit --nogit-fallback 
--norolestats" to fileter even more the output.

So adding Alexandre Belloni to my reply.



Also, are you using "git format-patch" to prepare the patch to be sent? 
In my case, some more context is added after "@@ -361,8 +361,8 @@". This 
help when reviewing patches.



Concerning your patch, I think that using devm_clk_get_enabled() instead 
of devm_clk_get() in the probe would be a better option. It changes the 
same order as you do and simplify the error handling path of the probe 
and the remove function.

CJ