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

Markus Probst <[email protected]> Tue, 11 Aug 2026 18:03:57 +0000
Newsgroups	org.kernel.vger.linux-rtc,dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-devicetree
Message-ID	<[email protected]>
On Wed, 2026-08-05 at 20:30 +0000, [email protected] wrote:
> 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?
Yes.
> 
> 
> [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?
No. AM/PM bit gets ignored in 24-hour mode.
signature.asc (application/pgp-signature, 870 B)