Re: [PATCH v7 3/4] hwmon: pmbus: add MPQ8646 driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `alarm_poll_interval_ms` variable is accessed and modified concurrently without any locking or atomic primitives, leading to a data race.
--

--- Patch [3]: [PATCH v7 3/4] hwmon: pmbus: add MPQ8646 driver ---
commit 013992e945508f7fa55c531019d24aec0d1d90cd
Author: Vincent Jardin <vjardin@free.fr>

hwmon: pmbus: add MPQ8646 driver

Add a new driver for the MPS MPQ8646 that is a PMBus device. Includes an
in-driver alarm-poll fallback for boards without SMBALERT.

> diff --git a/drivers/hwmon/pmbus/mpq8646.c b/drivers/hwmon/pmbus/mpq8646.c
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/mpq8646.c
[ ... ]
> +static int mpq8646_dbg_poll_interval_set(void *data, u64 val)
> +{
> +	struct mpq8646_priv *priv = data;
> +	bool was_off = !priv->alarm_poll_interval_ms;
> +
> +	priv->alarm_poll_interval_ms = (u32)val;

[Severity: Low]
Can this result in a data race when accessed concurrently by the polling worker?

If a user writes to the debugfs file while mpq8646_alarm_poll_work() is
running, the worker thread reads this same variable to determine the next
delay:

drivers/hwmon/pmbus/mpq8646.c:mpq8646_alarm_poll_work() {
    ...
    schedule_delayed_work(&priv->alarm_poll_work,
                          msecs_to_jiffies(priv->alarm_poll_interval_ms));
}

Should these accesses be protected with WRITE_ONCE() and READ_ONCE() to
prevent KCSAN warnings and ensure safe concurrent access?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-mpq8646_v0-v7-0-e7c7ad768d5d@free.fr?part=3