From: sashiko-bot@kernel.org
To: "Abdurrahman Hussain" <abdurrahman@nexthop.ai>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH RESEND v2 4/5] hwmon: (pmbus/adm1266) replace probe-time RTC seed with rtc_class device
Date: Tue, 12 May 2026 03:32:32 +0000 [thread overview]
Message-ID: <20260512033233.6868FC2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260511-adm1266-v2-4-7a6d34f0de5d@nexthop.ai>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing locking in RTC callbacks causes race condition with PMBus transactions.
- [Medium] Premature exposure of the RTC device before hardware initialization is complete.
--
commit 20e4a34f4a236495f598a1957552fb4fea44b3d3
Author: Abdurrahman Hussain <abdurrahman@nexthop.ai>
hwmon: (pmbus/adm1266) replace probe-time RTC seed with rtc_class device
This commit replaces the probe-time RTC seeding with an rtc_class device
backed by SET_RTC. This allows userspace tooling to drive the re-sync against
/dev/rtcN once it trusts the system clock.
> diff --git a/drivers/hwmon/pmbus/adm1266.c b/drivers/hwmon/pmbus/adm1266.c
> index 99e92a8365fb7..0dfb02db86837 100644
> --- a/drivers/hwmon/pmbus/adm1266.c
> +++ b/drivers/hwmon/pmbus/adm1266.c
[ ... ]
> +static int adm1266_rtc_read_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + u8 buf[I2C_SMBUS_BLOCK_MAX];
> + u32 secs;
> + int ret;
> + int i;
>
> - memset(write_buf, 0, sizeof(write_buf));
> + ret = i2c_smbus_read_block_data(client, ADM1266_SET_RTC, buf);
Since this RTC device is exposed to userspace, can this callback be invoked
concurrently with hwmon sysfs attributes managed by the PMBus core?
The PMBus core uses pmbus_lock to serialize multi-step sequences. If an RTC
I2C transaction interleaves in the middle of a PMBus sequence, can it disrupt
the device's internal state machine or cause unpredictable behavior?
Should this callback acquire pmbus_lock(client) (or its interruptible
variant) around the I2C transfer to prevent a race condition?
> + if (ret < 0)
> + return ret;
[ ... ]
> +static int adm1266_rtc_set_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> +
> + return adm1266_write_rtc(client, rtc_tm_to_time64(tm));
> +}
Does this callback also need to acquire pmbus_lock(client) around the I2C
transfer to prevent concurrent access with PMBus transactions?
[ ... ]
> @@ -553,7 +603,7 @@ static int adm1266_probe(struct i2c_client *client)
> if (ret < 0)
> return ret;
>
> - ret = adm1266_set_rtc(data);
> + ret = adm1266_register_rtc(data);
> if (ret < 0)
> return ret;
By registering the RTC device here, is the /dev/rtcX interface exposed to
userspace before pmbus_do_probe() completes the hardware discovery and
initialization sequence?
If a userspace process immediately opens the RTC device and issues read/write
commands, can the resulting I2C traffic interleave with the driver's
initial setup?
Should adm1266_register_rtc() be called at the end of the probe function,
after pmbus_do_probe() succeeds, to ensure the device is fully initialized
before it is accessed externally?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511-adm1266-v2-0-7a6d34f0de5d@nexthop.ai?part=4
next prev parent reply other threads:[~2026-05-12 3:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 7:51 [PATCH RESEND v2 0/5] hwmon: (pmbus/adm1266) blackbox, FW rev, rtc_class, GPIO label Abdurrahman Hussain
2026-05-11 7:51 ` [PATCH RESEND v2 1/5] hwmon: (pmbus/adm1266) add firmware_revision debugfs entry Abdurrahman Hussain
2026-05-11 7:51 ` [PATCH RESEND v2 2/5] hwmon: (pmbus/adm1266) add clear_blackbox " Abdurrahman Hussain
2026-05-12 0:52 ` sashiko-bot
2026-05-12 8:27 ` Abdurrahman Hussain
2026-05-12 9:19 ` Guenter Roeck
2026-05-12 10:20 ` Abdurrahman Hussain
2026-05-12 13:55 ` Guenter Roeck
2026-05-11 7:51 ` [PATCH RESEND v2 3/5] hwmon: (pmbus/adm1266) add powerup_counter " Abdurrahman Hussain
2026-05-12 1:29 ` sashiko-bot
2026-05-12 8:34 ` Abdurrahman Hussain
2026-05-11 7:51 ` [PATCH RESEND v2 4/5] hwmon: (pmbus/adm1266) replace probe-time RTC seed with rtc_class device Abdurrahman Hussain
2026-05-12 3:32 ` sashiko-bot [this message]
2026-05-12 8:42 ` Abdurrahman Hussain
2026-05-11 7:51 ` [PATCH RESEND v2 5/5] hwmon: (pmbus/adm1266) include adapter number in GPIO line label Abdurrahman Hussain
2026-05-11 14:10 ` [PATCH RESEND v2 0/5] hwmon: (pmbus/adm1266) blackbox, FW rev, rtc_class, GPIO label Guenter Roeck
2026-05-11 18:34 ` 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=20260512033233.6868FC2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=abdurrahman@nexthop.ai \
--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.