From: sashiko-bot@kernel.org
To: "Vincent Jardin" <vjardin@free.fr>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org,
linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v4 1/3] hwmon: pmbus: event notification with alarms
Date: Thu, 23 Jul 2026 21:50:48 +0000 [thread overview]
Message-ID: <20260723215048.EA8901F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260723-mpq8646_v0-v4-1-b6323d5fc524@free.fr>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the PMBus core notifies the wrong kobject when hardware monitoring events occur, functionally breaking IRQ-based notifications.
--
--- Patch [1]: [PATCH v4 1/3] hwmon: pmbus: event notification with alarms ---
commit eeca7812901a45049c95eb874da22e86da04ee7e
Author: Vincent Jardin <vjardin@free.fr>
hwmon: pmbus: event notification with alarms
Let's add an accessor for the hwmon class device the pmbus core
registered for an i2c_client. Export it with PMBUS so chip
drivers can call hwmon_notify_event() on per-sensor *_alarm
attributes from the driver's work items.
The needs: for boards when the chip's SMBALERT# pin is
not available for the CPU, pmbus_irq_setup() cannot deliver
poll(POLLPRI) wakes or udev change@... events on the inX_alarm
files. So the drivers can install a delayed_work-based polling
fallback (like the lm90 driver) that periodically reads STATUS_WORD
and calls hwmon_notify_event() on 0->1 transitions.
> diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
> index 3143b9e0316c4..6ba00ad732973 100644
> --- a/drivers/hwmon/pmbus/pmbus_core.c
> +++ b/drivers/hwmon/pmbus/pmbus_core.c
> @@ -695,6 +695,14 @@ const struct pmbus_driver_info *pmbus_get_driver_info(struct i2c_client *client)
> }
> EXPORT_SYMBOL_NS_GPL(pmbus_get_driver_info, "PMBUS");
>
> +struct device *pmbus_get_hwmon_device(struct i2c_client *client)
> +{
> + struct pmbus_data *data = i2c_get_clientdata(client);
> +
> + return data->hwmon_dev;
> +}
> +EXPORT_SYMBOL_NS_GPL(pmbus_get_hwmon_device, "PMBUS");
[Severity: High]
This isn't a bug introduced by this patch, but the PMBus core notifies the
wrong kobject when hardware monitoring events occur.
While this patch adds a way for polling drivers to notify the hwmon device
properly, does the standard interrupt path silently fail to notify userspace?
When an interrupt is triggered, the event propagates through
pmbus_fault_handler() -> _pmbus_get_flags() -> pmbus_notify().
Looking at pmbus_notify() in drivers/hwmon/pmbus/pmbus_core.c, it appears to
notify the I2C parent device's kobject rather than the hwmon device:
drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() {
...
if (reg == sreg && page == spage && (smask & flags)) {
dev_dbg(data->dev, "sysfs notify: %s", da->attr.name);
sysfs_notify(&data->dev->kobj, NULL, da->attr.name);
kobject_uevent(&data->dev->kobj, KOBJ_CHANGE);
flags &= ~smask;
}
...
}
Since the sysfs attributes are registered on the hwmon class device
(data->hwmon_dev), doesn't calling sysfs_notify() and kobject_uevent() on
data->dev->kobj prevent userspace applications from receiving POLLPRI or udev
events when an interrupt triggers an alarm?
Could this be fixed to use data->hwmon_dev instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-mpq8646_v0-v4-0-b6323d5fc524@free.fr?part=1
next prev parent reply other threads:[~2026-07-23 21:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 21:38 [PATCH v4 0/3] hwmon: pmbus: add MPS MPQ8646 support Vincent Jardin via B4 Relay
2026-07-23 21:38 ` Vincent Jardin
2026-07-23 21:38 ` [PATCH v4 1/3] hwmon: pmbus: event notification with alarms Vincent Jardin via B4 Relay
2026-07-23 21:38 ` Vincent Jardin
2026-07-23 21:50 ` sashiko-bot [this message]
2026-07-23 21:38 ` [PATCH v4 2/3] dt-bindings: hwmon: pmbus: add MPS MPQ8646 binding Vincent Jardin via B4 Relay
2026-07-23 21:38 ` Vincent Jardin
2026-07-23 21:45 ` sashiko-bot
2026-07-23 21:38 ` [PATCH v4 3/3] hwmon: pmbus: add MPQ8646 driver Vincent Jardin via B4 Relay
2026-07-23 21:38 ` Vincent Jardin
2026-07-23 21:54 ` sashiko-bot
2026-07-23 23:49 ` Guenter Roeck
2026-07-24 10:12 ` Vincent Jardin
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=20260723215048.EA8901F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vjardin@free.fr \
/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.