Re: [PATCH v3 2/5] rtc: s35390a: Add missing newline to dev_err

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

Pre-existing issues:
- [High] Desynchronization between software state and hardware 24-hour mode after initialization causes time corruption.
- [High] Alarm hour formatting erroneously adds PM bit in 24-hour mode, causing PM alarms to permanently fail.
--

--- Patch [2]: [PATCH v3 2/5] rtc: s35390a: Add missing newline to dev_err ---
commit 60df926a63720bd3dbdd3b4991c3149af682d4b0
Author: Markus Probst <[email protected]>

rtc: s35390a: Add missing newline to dev_err

This commit fixes a missing newline character in the dev_err call
within s35390a_probe() when alarm disabling fails.

> diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
> index b72eef4fb0997..4cfe7034c5165 100644
> --- a/drivers/rtc/rtc-s35390a.c
> +++ b/drivers/rtc/rtc-s35390a.c
> @@ -494,7 +494,7 @@ static int s35390a_probe(struct i2c_client *client)
>  		buf = 0;
>  		err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, &buf, 1);
>  		if (err < 0) {
> -			dev_err(dev, "error disabling alarm");
> +			dev_err(dev, "error disabling alarm\n");
>  			return err;
>  		}
>  	} else {

While reviewing this driver, I noticed a couple of pre-existing issues.

[Severity: High]
This isn't a bug introduced by this patch, but looking at s35390a_init(),
is it possible for the software state to become desynchronized from the
hardware 24-hour mode?

drivers/rtc/rtc-s35390a.c:s35390a_init() {
    ...
    initialize:
	buf = S35390A_FLAG_RESET | S35390A_FLAG_24H;
	ret = s35390a_set_reg(s35390a, S35390A_CMD_STATUS1, &buf, 1);
    ...
}

When this reset is triggered (for instance, via the RTC_VL_CLR ioctl or when
a brownout is detected), the hardware is explicitly switched to 24-hour mode
by setting S35390A_FLAG_24H.

However, s35390a->twentyfourhour is not updated to 1.

Does this mean subsequent calls to rtc_set_time() will incorrectly use the
12-hour formatting rules if twentyfourhour was previously 0, sending invalid
BCD formats to the chip and corrupting the timekeeping for PM hours?


[Severity: High]
This is a pre-existing issue, but I have a question about how the alarm hour
is formatted when the chip is operating in 24-hour mode:

drivers/rtc/rtc-s35390a.c:s35390a_rtc_set_alarm() {
    ...
	buf[S35390A_ALRM_BYTE_HOURS] = s35390a_hr2reg(s35390a,
			alm->time.tm_hour) | 0x80;
	buf[S35390A_ALRM_BYTE_MINS] = bin2bcd(alm->time.tm_min) | 0x80;

	if (alm->time.tm_hour >= 12)
		buf[S35390A_ALRM_BYTE_HOURS] |= 0x40;
    ...
}

If the chip is in 24-hour mode, s35390a_hr2reg() will already return the
standard 24-hour BCD value (e.g., 0x15 for 15:00).

Could the unconditional bitwise-OR with 0x40 (the PM bit) corrupt the alarm
time value in 24-hour mode, causing PM alarms to permanently fail because the
hardware comparator expects a standard 24-hour BCD value?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2