Re: [PATCH v4 06/15] rtc: rzn1: Fix alarm range check truncation on 32-bit systems

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Race condition in rzn1_rtc_set_alarm between hardware programming and the alarm interrupt handler.
--

--- Patch [6]: [PATCH v4 06/15] rtc: rzn1: Fix alarm range check truncation on 32-bit systems ---
commit 87931837ad8bba978fe3d99a5140167b545c3e4d
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

rtc: rzn1: Fix alarm range check truncation on 32-bit systems

This commit changes the types of alarm and farest to time64_t to prevent
truncation on 32-bit systems. It also replaces time_after() with a direct
signed comparison.

> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index d03d252fdfe1f..94d592e88a044 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c

[ ... ]

> @@ -269,7 +269,7 @@ static int rzn1_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
>  	/* We cannot set alarms more than one week ahead */
>  	farest = rtc_tm_to_time64(&tm_now) + rtc->rtcdev->alarm_offset_max;
>  	alarm = rtc_tm_to_time64(tm);
> -	if (time_after(alarm, farest))
> +	if (alarm > farest)
>  		return -ERANGE;
>  
>  	writel(bin2bcd(tm->tm_min), rtc->base + RZN1_RTC_ALM);

[Severity: High]
This is a pre-existing issue, but can this sequence of register writes
trigger a spurious interrupt?

In drivers/rtc/rtc-rzn1.c:rzn1_rtc_set_alarm(), the driver writes to the
hardware alarm registers without first explicitly disabling the alarm
interrupt.

If the RTC core enqueues a new alarm while a previous alarm is active,
could the hardware registers temporarily match the current time during
these sequential writes and trigger an interrupt?

If an interrupt fires here, it looks like rzn1_rtc_alarm_irq() would
execute using the old, stale rtc->tm_alarm state, since it hasn't been
updated yet. Could this cause it to incorrectly switch to 1-second
interrupts or fire a spurious event?

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