Re: [PATCH v2 05/10] 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] Alarm weekday calculation fails when crossing month boundaries, causing the alarm to be scheduled on the wrong day.
--

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

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

This commit resolves the truncation of the alarm and farest timestamps on
32-bit systems. It achieves this by declaring these variables as time64_t
and replacing time_after() with a direct signed comparison.

> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index 866ff595188d8..9969bcefede72 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c

[ ... ]

> @@ -260,8 +261,8 @@ static int rzn1_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
>  {
>  	struct rzn1_rtc *rtc = dev_get_drvdata(dev);
>  	struct rtc_time *tm = &alrm->time, tm_now;
> -	unsigned long alarm, farest;
>  	unsigned int days_ahead, wday;
> +	time64_t alarm, farest;
>  	int ret;
>  
>  	ret = rzn1_rtc_read_time(dev, &tm_now);
> @@ -271,7 +272,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;
>  
>  	/* Convert alarm day into week day */

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing
issue in how the weekday is calculated just below this in
rzn1_rtc_set_alarm().

When an alarm is set for the following month (for instance, setting an
alarm for the 1st of next month while today is the 31st), this calculation
is used:

	days_ahead = tm->tm_mday - tm_now.tm_mday;
	wday = (tm_now.tm_wday + days_ahead) % 7;

Since this only subtracts the day-of-month, wouldn't crossing a month
boundary result in a negative value (e.g., 1 - 31 = -30), which then
underflows the unsigned int days_ahead?

This would then result in an incorrect weekday offset being added to the
current weekday, programming the wrong weekday into the RZN1_RTC_ALW
register.

Should this logic be updated to safely handle month boundaries?

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