All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Guenter Roeck" <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH] hwmon: Ensure that 'dev' passed to hwmon_notify_event() is a hwmon device
Date: Fri, 21 Aug 2026 05:30:58 +0000	[thread overview]
Message-ID: <20260821053059.7B82F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260821052258.672697-1-linux@roeck-us.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The newly added WARN will be unconditionally triggered by the existing bnxt driver, causing a loud regression.
--

--- Patch [1]: [PATCH] hwmon: Ensure that 'dev' passed to hwmon_notify_event() is a hwmon device ---
commit d2961b1d473d8c128ab5a2aa551a3dc59e8bed39
Author: Guenter Roeck <linux@roeck-us.net>

hwmon: Ensure that 'dev' passed to hwmon_notify_event() is a hwmon device

This patch enforces that the device passed to hwmon_notify_event() is actually
a hardware monitoring device. It introduces a warning and aborts the event
notification if an incorrect device class is provided.

> diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
> index 41755910a25a0..4110b5c45ee8d 100644
> --- a/drivers/hwmon/hwmon.c
> +++ b/drivers/hwmon/hwmon.c
[ ... ]
> @@ -782,6 +787,9 @@ int hwmon_notify_event(struct device *dev, enum hwmon_sensor_types type,
>  	const char *template;
>  	int base;
>  
> +	if (WARN(!is_hwmon_device(dev), "%s is not a hardware monitoring device\n",
> +		 dev_name(dev)))
> +		return -EINVAL;

[Severity: High]
This isn't a bug introduced by this patch, but will this strict check cause a
regression for the bnxt driver?

Looking at bnxt_hwmon_notify_event() in
drivers/net/ethernet/broadcom/bnxt/bnxt_hwmon.c, it currently passes the
parent PCI device instead of the hwmon device:

void bnxt_hwmon_notify_event(struct bnxt *bp)
{
	u32 attr;
	...
	hwmon_notify_event(&bp->pdev->dev, hwmon_temp, attr, 0);
}

Since the device passed here is not a hwmon device, won't this new WARN
trigger unconditionally on every thermal event for bnxt hardware?

For systems configured with panic_on_warn, wouldn't this lead to a panic
during normal hardware thermal events?

>  	if (type >= ARRAY_SIZE(__templates))
>  		return -EINVAL;
>  	if (attr >= __templates_size[type])

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260821052258.672697-1-linux@roeck-us.net?part=1

      reply	other threads:[~2026-08-21  5:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21  5:22 [PATCH] hwmon: Ensure that 'dev' passed to hwmon_notify_event() is a hwmon device Guenter Roeck
2026-08-21  5:30 ` sashiko-bot [this message]

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=20260821053059.7B82F1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=sashiko-reviews@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.