Re: [PATCH v2 08/10] rtc: rzn1: Consistently use dev_err_probe()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Premature pm_runtime_put() in remove callback leads to a potential bus fault or kernel panic due to devres teardown ordering.
--

commit 20388d9c3bb9eb8111711742d828f2997e736384
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

rtc: rzn1: Consistently use dev_err_probe()

This patch updates rzn1_rtc_probe() to use dev_err_probe() when the alarm
interrupt request fails. This brings the error handling into alignment with
the rest of the probe function.

> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index 244d0fc70fdad..d990075839c13 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
> @@ -471,7 +471,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
>  
>  	ret = devm_request_irq(dev, irq, rzn1_rtc_alarm_irq, 0, "RZN1 RTC Alarm", rtc);
>  	if (ret) {
> -		dev_err(dev, "RTC alarm interrupt not available\n");
> +		dev_err_probe(dev, ret, "RTC alarm interrupt not available\n");
>  		goto dis_runtime_pm;
>  	}

[Severity: High]
This isn't a bug introduced by this patch, but since we are looking at driver
error handling and teardown paths, is there a potential use-after-suspend
issue during device removal?

Since the RTC is registered using devm_rtc_register_device() in
rzn1_rtc_probe(), it remains registered and accessible to user space until
the devres teardown runs, which happens after rzn1_rtc_remove() returns.

However, rzn1_rtc_remove() manually drops the runtime PM reference:

drivers/rtc/rtc-rzn1.c:rzn1_rtc_remove() {
	...
	/* Disable all interrupts */
	writel(0, rtc->base + RZN1_RTC_CTL1);

	pm_runtime_put(&pdev->dev);
}

If a user-space process accesses the RTC device (like reading the time via
ioctl) precisely during driver unbinding after pm_runtime_put() is called,
would this access hardware registers while the clock is gated and trigger
a kernel panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701142953.2014895-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=8