* [PATCH 1/2] rtc: Add flag for dynamic hctosys control
2026-10-21 4:24 [PATCH 0/2] rtc: Prevent hctosys from using invalid RTC time Akashdeep Kaur
@ 2026-10-21 4:24 ` Akashdeep Kaur
2026-10-21 4:37 ` sashiko-bot
2026-10-21 4:24 ` [PATCH 2/2] rtc: ti-k3: Mark RTC time as invalid without battery backup Akashdeep Kaur
2026-10-21 7:13 ` [PATCH 0/2] rtc: Prevent hctosys from using invalid RTC time Alexandre Belloni
2 siblings, 1 reply; 7+ messages in thread
From: Akashdeep Kaur @ 2026-10-21 4:24 UTC (permalink / raw)
To: praneeth, nm, vigneshr, alexandre.belloni, linux-rtc,
linux-kernel, sebin.francis
Cc: s-tripathi1, vishalm, k-willis, a-kaur
Add flag to indicate whether RTC has valid absolute time on current
boot. This allows drivers to dynamically communicate RTC validity
per-boot to prevent hctosys from setting system time from invalid
RTC values.
The flag defaults to true for backward compatibility with existing
drivers.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/rtc/class.c | 15 +++++++++++++++
include/linux/rtc.h | 7 +++++++
2 files changed, 22 insertions(+)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 01ba04028f1f..cec27c476545 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -63,6 +63,18 @@ static void rtc_hctosys(struct rtc_device *rtc)
.tv_nsec = NSEC_PER_SEC >> 1,
};
+ /*
+ * If the RTC does not have valid time, do not set system time at boot.
+ * This can happen when RTC loses power or has never been initialized.
+ * PM resume compensation will still work via rtc_resume().
+ */
+ if (!rtc->time_is_valid) {
+ dev_info(rtc->dev.parent,
+ "hctosys: RTC time not valid, skipping\n");
+ err = -EINVAL;
+ goto err_read;
+ }
+
err = rtc_read_time(rtc, &tm);
if (err) {
dev_err(rtc->dev.parent,
@@ -243,6 +255,9 @@ static struct rtc_device *rtc_allocate_device(void)
hrtimer_setup(&rtc->pie_timer, rtc_pie_update_irq, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
rtc->pie_enabled = 0;
+ /* Assume RTC has valid time by default. Drivers can override. */
+ rtc->time_is_valid = true;
+
set_bit(RTC_FEATURE_ALARM, rtc->features);
set_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features);
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 0f43b5027235..f6f982610938 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -152,6 +152,13 @@ struct rtc_device {
time64_t offset_secs;
bool set_start_time;
+ /*
+ * Set by drivers to indicate RTC has valid absolute time.
+ * Used to prevent hctosys from using RTC when time is invalid
+ * (e.g., lost power, never initialized). PM compensation is unaffected.
+ */
+ bool time_is_valid;
+
#ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL
struct work_struct uie_task;
struct timer_list uie_timer;
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH 1/2] rtc: Add flag for dynamic hctosys control
2026-10-21 4:24 ` [PATCH 1/2] rtc: Add flag for dynamic hctosys control Akashdeep Kaur
@ 2026-10-21 4:37 ` sashiko-bot
2026-10-21 5:25 ` Akashdeep Kaur
0 siblings, 1 reply; 7+ messages in thread
From: sashiko-bot @ 2026-10-21 4:37 UTC (permalink / raw)
To: Akashdeep Kaur, linux-rtc; +Cc: Alexandre Belloni
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] rtc: checking time_is_valid only in rtc_hctosys() exposes invalid RTC time
--
commit 378dbc5f51408e7a59e18fa3e61590784e92a232
Author: Akashdeep Kaur <a-kaur@ti.com>
rtc: Add flag for dynamic hctosys control
This commit adds a time_is_valid flag to struct rtc_device and checks it in
rtc_hctosys() so drivers can prevent setting the system clock from an
uninitialized or power-lost hardware clock at boot.
> diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
> index 01ba04028f1f1..cec27c476545e 100644
> --- a/drivers/rtc/class.c
> +++ b/drivers/rtc/class.c
> @@ -63,6 +63,18 @@ static void rtc_hctosys(struct rtc_device *rtc)
> .tv_nsec = NSEC_PER_SEC >> 1,
> };
>
> + /*
> + * If the RTC does not have valid time, do not set system time at boot.
> + * This can happen when RTC loses power or has never been initialized.
> + * PM resume compensation will still work via rtc_resume().
> + */
> + if (!rtc->time_is_valid) {
> + dev_info(rtc->dev.parent,
> + "hctosys: RTC time not valid, skipping\n");
> + err = -EINVAL;
> + goto err_read;
> + }
> +
> err = rtc_read_time(rtc, &tm);
> if (err) {
> dev_err(rtc->dev.parent,
[Severity: Medium]
When a driver sets rtc->time_is_valid to false instead of returning an error
from ops->read_time(), checking rtc->time_is_valid only in rtc_hctosys()
leaves rtc_read_time() in drivers/rtc/interface.c returning 0 with bogus
1970-01-01 time to all other callers:
drivers/rtc/interface.c:rtc_read_time() {
err = mutex_lock_interruptible(&rtc->ops_lock);
if (err)
return err;
err = __rtc_read_time(rtc, tm);
mutex_unlock(&rtc->ops_lock);
...
return err;
}
drivers/rtc/dev.c:rtc_dev_ioctl() {
case RTC_RD_TIME:
mutex_unlock(&rtc->ops_lock);
err = rtc_read_time(rtc, &tm);
if (err < 0)
return err;
}
On boot before rtc_set_time() is called, any userspace read via
rtc_dev_ioctl() -> rtc_read_time() (such as hwclock --hctosys, timedatectl,
or chronyd), sysfs reads in date_show(), time_show(), and since_epoch_show()
in drivers/rtc/sysfs.c, procfs reads in rtc_proc_show(), and alarm
initialization in __devm_rtc_register_device() -> __rtc_read_alarm() ->
rtc_initialize_alarm() -> rtc_read_time() will all succeed and consume the
uninitialized 1970-01-01 timestamp.
Additionally, rtc_set_time() in drivers/rtc/interface.c never updates
rtc->time_is_valid to true once a valid time is written.
Could drivers return -EINVAL from ops->read_time() until ops->set_time() is
called (which already causes rtc_hctosys() to skip setting system time via
rtc_read_time()), or should __rtc_read_time() and rtc_set_time() check and
update this flag so all callers see consistent validity reporting?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261021042435.3895543-1-a-kaur@ti.com?part=1
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 1/2] rtc: Add flag for dynamic hctosys control
2026-10-21 4:37 ` sashiko-bot
@ 2026-10-21 5:25 ` Akashdeep Kaur
0 siblings, 0 replies; 7+ messages in thread
From: Akashdeep Kaur @ 2026-10-21 5:25 UTC (permalink / raw)
To: sashiko-reviews, linux-rtc; +Cc: Alexandre Belloni
On 21/10/26 10:07, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] rtc: checking time_is_valid only in rtc_hctosys() exposes invalid RTC time
> --
>
> commit 378dbc5f51408e7a59e18fa3e61590784e92a232
> Author: Akashdeep Kaur <a-kaur@ti.com>
>
> rtc: Add flag for dynamic hctosys control
>
> This commit adds a time_is_valid flag to struct rtc_device and checks it in
> rtc_hctosys() so drivers can prevent setting the system clock from an
> uninitialized or power-lost hardware clock at boot.
>
>> diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
>> index 01ba04028f1f1..cec27c476545e 100644
>> --- a/drivers/rtc/class.c
>> +++ b/drivers/rtc/class.c
>> @@ -63,6 +63,18 @@ static void rtc_hctosys(struct rtc_device *rtc)
>> .tv_nsec = NSEC_PER_SEC >> 1,
>> };
>>
>> + /*
>> + * If the RTC does not have valid time, do not set system time at boot.
>> + * This can happen when RTC loses power or has never been initialized.
>> + * PM resume compensation will still work via rtc_resume().
>> + */
>> + if (!rtc->time_is_valid) {
>> + dev_info(rtc->dev.parent,
>> + "hctosys: RTC time not valid, skipping\n");
>> + err = -EINVAL;
>> + goto err_read;
>> + }
>> +
>> err = rtc_read_time(rtc, &tm);
>> if (err) {
>> dev_err(rtc->dev.parent,
>
> [Severity: Medium]
> When a driver sets rtc->time_is_valid to false instead of returning an error
> from ops->read_time(), checking rtc->time_is_valid only in rtc_hctosys()
> leaves rtc_read_time() in drivers/rtc/interface.c returning 0 with bogus
> 1970-01-01 time to all other callers:
>
> drivers/rtc/interface.c:rtc_read_time() {
> err = mutex_lock_interruptible(&rtc->ops_lock);
> if (err)
> return err;
>
> err = __rtc_read_time(rtc, tm);
> mutex_unlock(&rtc->ops_lock);
> ...
> return err;
> }
>
> drivers/rtc/dev.c:rtc_dev_ioctl() {
> case RTC_RD_TIME:
> mutex_unlock(&rtc->ops_lock);
>
> err = rtc_read_time(rtc, &tm);
> if (err < 0)
> return err;
> }
>
> On boot before rtc_set_time() is called, any userspace read via
> rtc_dev_ioctl() -> rtc_read_time() (such as hwclock --hctosys, timedatectl,
> or chronyd), sysfs reads in date_show(), time_show(), and since_epoch_show()
> in drivers/rtc/sysfs.c, procfs reads in rtc_proc_show(), and alarm
> initialization in __devm_rtc_register_device() -> __rtc_read_alarm() ->
> rtc_initialize_alarm() -> rtc_read_time() will all succeed and consume the
> uninitialized 1970-01-01 timestamp.
>
> Additionally, rtc_set_time() in drivers/rtc/interface.c never updates
> rtc->time_is_valid to true once a valid time is written.
>
> Could drivers return -EINVAL from ops->read_time() until ops->set_time() is
> called (which already causes rtc_hctosys() to skip setting system time via
> rtc_read_time()), or should __rtc_read_time() and rtc_set_time() check and
> update this flag so all callers see consistent validity reporting?
>
> [ ... ]
>
Thank you for the review. The time_is_valid flag is specifically to
control boot-time synchronization, not to block RTC reads.
The RTC hardware is readable - userspace can read it via hwclock/sysfs.
Reading "1970-01-01" is acceptable as it reflects actual hardware state.
The problem we're solving is specific: preventing boot-time sync from
overwriting correct system time (from bootloader/NTP) with uninitialized
RTC value.
Returning -EINVAL from __rtc_read_time() would block all reads, which is
not the intent. The RTC is readable; we just shouldn't use it to set
system time on this particular boot.
Regards,
Akashdeep Kaur
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 2/2] rtc: ti-k3: Mark RTC time as invalid without battery backup
2026-10-21 4:24 [PATCH 0/2] rtc: Prevent hctosys from using invalid RTC time Akashdeep Kaur
2026-10-21 4:24 ` [PATCH 1/2] rtc: Add flag for dynamic hctosys control Akashdeep Kaur
@ 2026-10-21 4:24 ` Akashdeep Kaur
2026-10-21 4:37 ` sashiko-bot
2026-10-21 7:13 ` [PATCH 0/2] rtc: Prevent hctosys from using invalid RTC time Alexandre Belloni
2 siblings, 1 reply; 7+ messages in thread
From: Akashdeep Kaur @ 2026-10-21 4:24 UTC (permalink / raw)
To: praneeth, nm, vigneshr, alexandre.belloni, linux-rtc,
linux-kernel, sebin.francis
Cc: s-tripathi1, vishalm, k-willis, a-kaur
TI K3 RTC typically has no battery backup. Prevent HCTOSYS from
overwriting valid system time (established by bootloader or early
NTP sync) with invalid RTC value.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/rtc/rtc-ti-k3.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/rtc/rtc-ti-k3.c b/drivers/rtc/rtc-ti-k3.c
index 8df00319cb6b..99fdf1192675 100644
--- a/drivers/rtc/rtc-ti-k3.c
+++ b/drivers/rtc/rtc-ti-k3.c
@@ -613,6 +613,13 @@ static int ti_k3_rtc_probe(struct platform_device *pdev)
else
device_set_wakeup_capable(dev, true);
+ /*
+ * TI K3 RTC has no battery backup in typical configurations.
+ * Mark time as invalid to prevent hctosys from overwriting
+ * correct system time (from bootloader/NTP) with invalid RTC value.
+ */
+ priv->rtc_dev->time_is_valid = false;
+
ret = devm_rtc_register_device(priv->rtc_dev);
if (ret)
return ret;
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 0/2] rtc: Prevent hctosys from using invalid RTC time
2026-10-21 4:24 [PATCH 0/2] rtc: Prevent hctosys from using invalid RTC time Akashdeep Kaur
2026-10-21 4:24 ` [PATCH 1/2] rtc: Add flag for dynamic hctosys control Akashdeep Kaur
2026-10-21 4:24 ` [PATCH 2/2] rtc: ti-k3: Mark RTC time as invalid without battery backup Akashdeep Kaur
@ 2026-10-21 7:13 ` Alexandre Belloni
2 siblings, 0 replies; 7+ messages in thread
From: Alexandre Belloni @ 2026-10-21 7:13 UTC (permalink / raw)
To: Akashdeep Kaur
Cc: praneeth, nm, vigneshr, linux-rtc, linux-kernel, sebin.francis,
s-tripathi1, vishalm, k-willis
Hello,
On 21/10/2026 09:54:33+0530, Akashdeep Kaur wrote:
> The kernel's boot-time RTC synchronization blindly trusts the RTC
> value when setting system time, but RTCs may have invalid time
> depending on the boot path:
>
> - On first cold boot: RTC may have lost power, time is invalid
> - After low-power mode (RTC-only) cold boot: RTC retained power, time
> is valid
>
> On normal cold boot where bootloader or NTP has already established
> correct time, boot-time sync (triggered when RTC driver loads as
> module or probes at boot) can overwrite it with invalid RTC data,
> causing time rollback to 1970. However, on boot from RTC-only power
> mode, the RTC has valid time and boot-time sync should work to
> restore system time from RTC.
>
> This series adds a flag that drivers set dynamically per-boot to
> indicate whether RTC has valid time. Drivers check at probe if RTC
> retained power through this specific boot. Boot-time sync checks this
> flag before setting system time. This enables correct behavior for
> both boot paths while keeping PM suspend/resume compensation
> unaffected.
The proper way to do this is to return -EINVAL in read_time until you
know the date is correct. There is no need for an extra flag for the core.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 7+ messages in thread