Re: [PATCH 1/5] hwmon: (pmbus/adm1266) seed timestamp from the real-time clock

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Fetching wall-clock time during device probe yields an uninitialized value, defeating the purpose of the patch.
- [Medium] Switching from monotonic time to wall-clock time introduces a Year 2038 silent truncation bug.
--

commit a6888c73c1a25c1329fffa916ee8e1654b5eaa1a
Author: Abdurrahman Hussain <abdurrahman@nexthop.ai>

hwmon: (pmbus/adm1266) seed timestamp from the real-time clock

This commit switches the adm1266 driver to use ktime_get_real_seconds()
instead of ktime_get_seconds() to seed the chip's SET_RTC register.
The intention is to provide wall-clock time for blackbox records.

> diff --git a/drivers/hwmon/pmbus/adm1266.c b/drivers/hwmon/pmbus/adm1266.c
> index d90f8f80be8e0..a86666c73a5e9 100644
> --- a/drivers/hwmon/pmbus/adm1266.c
> +++ b/drivers/hwmon/pmbus/adm1266.c
> @@ -432,7 +432,7 @@ static int adm1266_set_rtc(struct adm1266_data *data)
>  	char write_buf[6];
>  	int i;
>  
> -	kt = ktime_get_seconds();
> +	kt = ktime_get_real_seconds();

Since adm1266_set_rtc() is called during device probe, will the wall-clock
time be initialized at this point?

During early boot, before the system timekeeper is synchronized with a
hardware RTC or NTP, ktime_get_real_seconds() might return a near-zero
value. Would this effectively behave like a monotonic timestamp and
silently defeat the purpose of the patch?

Additionally, does the 4-byte serialization loop in this function silently
truncate the 64-bit kt value?

drivers/hwmon/pmbus/adm1266.c:adm1266_set_rtc() {
    ...
    for (i = 0; i < 4; i++)
        write_buf[2 + i] = (kt >> (i * 8)) & 0xFF;
    ...
}

Because kt is now a wall-clock timestamp instead of system uptime, a 4-byte
field will overflow in the year 2038.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515-adm1266-fixes-v1-0-1c1ea1349cfe@nexthop.ai?part=1