Re: [PATCH 2/2] rtc: renesas-rtca3: Join interrupt handlers before unregistering the RTC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] rtc: renesas-rtca3: mixing goto and scoped_guard in rtca3_set_alarm()
--

commit 847b7d6e6378d6cee33935541f2c60ff982bf01d
Author: Myeonghun Pak <mhun512@gmail.com>

rtc: renesas-rtca3: Join interrupt handlers before unregistering the RTC

This commit addresses an issue where interrupt handlers might still run
after the RTC operations have been cleared. It tracks a stopping state
to reject setup requests and disables IRQs synchronously during removal.

> diff --git a/drivers/rtc/rtc-renesas-rtca3.c b/drivers/rtc/rtc-renesas-rtca3.c
> index c304ed60edc6c..9b177a131c272 100644
> --- a/drivers/rtc/rtc-renesas-rtca3.c
> +++ b/drivers/rtc/rtc-renesas-rtca3.c
[ ... ]
> @@ -392,6 +399,9 @@ static int rtca3_set_alarm(struct device *dev, struct rtc_wkalrm *wkalrm)
>  	int ret;
>  
>  	scoped_guard(spinlock_irqsave, &priv->lock) {
> +		if (priv->stopping)
> +			return -ENODEV;
> +

[Severity: Low]
Does this mix goto-based error handling and scope-based cleanup helpers in
the same function?

According to include/linux/cleanup.h and subsystem guidelines, usage of
"goto" and cleanup helpers should never be mixed in the same function. All
resources that need a "goto" cleanup should either be converted to
scope-based cleanup or remain manually managed.

In this case, rtca3_set_alarm() uses
scoped_guard(spinlock_irqsave, &priv->lock) here, but later relies on:

    if (ret)
        goto setup_failed;

which violates the cleanup helper guidelines and creates confusing ownership
and control flow semantics during alarm setup failures.

>  		tmp = readb(priv->base + RTCA3_RCR2);
>  		if (!(tmp & RTCA3_RCR2_START))
>  			return -EPERM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261011225657.rtca3-irq-ordering.0@gmail.com?part=2