[PATCH] rtc: meson: fix refcount leak in meson_rtc_get_bus

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch attempts to fix a non-existent refcount leak by adding reset_control_rearm() to an exclusive reset control (where it is a no-op). Furthermore, if the reset control were actually shared, adding reset_control_rearm() to the error path would cause a double-decrement underflow bug.
--

commit c52dd99142fd976704b680f05d5ba9c353703d91
Author: WenTao Liang <vulab at iscas.ac.cn>

rtc: meson: fix refcount leak in meson_rtc_get_bus

This commit attempts to fix a refcount leak by adding reset_control_rearm()
to both the error and success paths of reset_control_reset() in
meson_rtc_get_bus().

> diff --git a/drivers/rtc/rtc-meson.c b/drivers/rtc/rtc-meson.c
> index 21eceb9e2e134..3c45cd761a15a 100644
> --- a/drivers/rtc/rtc-meson.c
> +++ b/drivers/rtc/rtc-meson.c
[ ... ]
> @@ -146,8 +146,12 @@ static int meson_rtc_get_bus(struct meson_rtc *rtc)
>  		dev_warn(rtc->dev, "failed to get bus, resetting RTC\n");
>  
>  		ret = reset_control_reset(rtc->reset);
> -		if (ret)
> +		if (ret) {
> +			reset_control_rearm(rtc->reset);

[Severity: Medium]
Is this reset control actually shared? The rtc->reset appears to be acquired
as an exclusive reset control, where reset_control_rearm() is documented to
be a no-op and triggered_count is not used.

Also, if this were a shared reset control, would calling
reset_control_rearm() on the error path cause a double-decrement underflow?

The reset core framework automatically rolls back the triggered_count
increment if the underlying hardware reset fails. Manually calling
reset_control_rearm() after a failure might drop the counter below zero
and trigger a warning.

>  			return ret;
> +		}
> +
> +		reset_control_rearm(rtc->reset);
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611035605.59906-1-vulab@iscas.ac.cn?part=1