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

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 conc=
urrently 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 <[email protected]>

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 =3D data;
> +	bool was_off =3D !priv->alarm_poll_interval_ms;
> +
> +	priv->alarm_poll_interval_ms =3D (u32)val;

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

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?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260730-mpq8646_v0=
[email protected]?part=3D3