From: sashiko-bot@kernel.org
To: "Abdurrahman Hussain via B4 Relay"
<devnull+abdurrahman.nexthop.ai@kernel.org>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH 1/7] hwmon: (pmbus/adm1266) use wall-clock seconds for SET_RTC
Date: Fri, 08 May 2026 23:48:54 +0000 [thread overview]
Message-ID: <20260508234854.A7BE4C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260508-adm1266-v1-1-ec08bf29e0ce@nexthop.ai>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Silent truncation of a 64-bit real-time timestamp causes Y2038 arithmetic overflow.
- [High] Unconditionally overwriting the hardware RTC during probe destroys retained state and defeats cross-reboot correlation.
--
commit 260e18847f33c3f0022668e0092b4f93049b2ea6
Author: Abdurrahman Hussain <abdurrahman@nexthop.ai>
hwmon: (pmbus/adm1266) use wall-clock seconds for SET_RTC
This patch modifies the ADM1266 driver to seed the device internal RTC
with wall-clock time instead of monotonic time since boot. This change is
intended to allow cross-reboot correlation of 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();
Can this lead to an arithmetic overflow? ktime_get_real_seconds returns
a 64-bit time64_t, but the subsequent serialization loop only processes
4 bytes:
for (i = 0; i < 4; i++)
write_buf[2 + i] = (kt >> (i * 8)) & 0xFF;
This silently truncates the upper 32 bits of the timestamp. Should the value
be clamped or bounds-checked to prevent silent wrap-around?
Also, if adm1266_set_rtc is called unconditionally during early probe, will
ktime_get_real_seconds return an uninitialized time near the 1970 epoch
if the system wall-clock has not yet been synchronized via an external RTC
or userspace NTP?
Overwriting the internal hardware RTC on every probe could destroy any valid
time state retained across a warm reboot, breaking the stated goal of
cross-reboot log correlation. Does this code need to preserve the existing
RTC state rather than seeding it at probe?
>
> memset(write_buf, 0, sizeof(write_buf));
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260508-adm1266-v1-0-ec08bf29e0ce@nexthop.ai?part=1
next prev parent reply other threads:[~2026-05-08 23:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 23:33 [PATCH 0/7] hwmon: (pmbus/adm1266) RTC fix, blackbox, FW rev, rtc_class Abdurrahman Hussain
2026-05-08 23:33 ` Abdurrahman Hussain via B4 Relay
2026-05-08 23:33 ` [PATCH 1/7] hwmon: (pmbus/adm1266) use wall-clock seconds for SET_RTC Abdurrahman Hussain
2026-05-08 23:33 ` Abdurrahman Hussain via B4 Relay
2026-05-08 23:48 ` sashiko-bot [this message]
2026-05-08 23:33 ` [PATCH 2/7] hwmon: (pmbus/adm1266) write fractional-seconds field of SET_RTC Abdurrahman Hussain
2026-05-08 23:33 ` Abdurrahman Hussain via B4 Relay
2026-05-09 0:06 ` sashiko-bot
2026-05-08 23:33 ` [PATCH 3/7] hwmon: (pmbus/adm1266) add firmware_revision debugfs entry Abdurrahman Hussain
2026-05-08 23:33 ` Abdurrahman Hussain via B4 Relay
2026-05-09 0:38 ` sashiko-bot
2026-05-08 23:33 ` [PATCH 4/7] hwmon: (pmbus/adm1266) add clear_blackbox " Abdurrahman Hussain
2026-05-08 23:33 ` Abdurrahman Hussain via B4 Relay
2026-05-09 1:10 ` sashiko-bot
2026-05-08 23:33 ` [PATCH 5/7] hwmon: (pmbus/adm1266) add powerup_counter " Abdurrahman Hussain
2026-05-08 23:33 ` Abdurrahman Hussain via B4 Relay
2026-05-09 1:48 ` sashiko-bot
2026-05-08 23:33 ` [PATCH 6/7] hwmon: (pmbus/adm1266) register rtc_class device backed by SET_RTC Abdurrahman Hussain
2026-05-08 23:33 ` Abdurrahman Hussain via B4 Relay
2026-05-09 2:26 ` sashiko-bot
2026-05-08 23:33 ` [PATCH 7/7] hwmon: (pmbus/adm1266) include adapter number in GPIO line label Abdurrahman Hussain
2026-05-08 23:33 ` Abdurrahman Hussain via B4 Relay
2026-05-09 2:39 ` sashiko-bot
2026-05-09 14:14 ` [PATCH 0/7] hwmon: (pmbus/adm1266) RTC fix, blackbox, FW rev, rtc_class Guenter Roeck
2026-05-09 21:58 ` Abdurrahman Hussain
2026-05-09 23:49 ` Guenter Roeck
2026-05-11 3:46 ` Abdurrahman Hussain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260508234854.A7BE4C2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=devnull+abdurrahman.nexthop.ai@kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=sashiko@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.