From: Damien Le Moal <dlemoal@kernel.org>
To: Louis Sautier <sautier.louis@gmail.com>,
Sathya Prakash <sathya.prakash@broadcom.com>,
Sreekanth Reddy <sreekanth.reddy@broadcom.com>,
Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>,
Ranjan Kumar <ranjan.kumar@broadcom.com>,
"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
MPT-FusionLinux.pdl@broadcom.com, linux-scsi@vger.kernel.org,
linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] scsi: mpt3sas: add hwmon support
Date: Tue, 30 Jun 2026 09:28:40 +0900 [thread overview]
Message-ID: <aeb83cdb-616e-49b8-a791-3748dae60133@kernel.org> (raw)
In-Reply-To: <20260613023833.3163507-3-sautier.louis@gmail.com>
On 6/13/26 11:38, Louis Sautier wrote:
> Expose the IOC and board temperature sensors of LSI / Broadcom SAS
> HBAs through hwmon. Readings come from MPI IO Unit Page 7 via the
> accessor added in the preceding patch.
>
> The same fields are exposed by Broadcom's userspace tooling
> through the /dev/mpt[23]ctl ioctl path (typically root-only):
> IOCTemperature and BoardTemperature in lsiutil; ROC and Controller
> in storcli. With this driver, sensors(1) shows them unprivileged:
>
> $ sensors mpt3sas-pci-0200
> mpt3sas-pci-0200
> Adapter: PCI adapter
> IOC: +42.0°C
>
> Each channel is gated independently by its *TemperatureUnits field
> through is_visible(); cards that populate only one sensor expose
> only one input file, and cards that populate neither do not register
> an hwmon device.
>
> The hwmon code is gated directly on CONFIG_HWMON. IS_REACHABLE() is
> used rather than IS_ENABLED() so that SCSI_MPT3SAS=y with HWMON=m
> still builds; in that configuration, the sensors are not exposed
> (same pattern as i915 and xe).
>
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Louis Sautier <sautier.louis@gmail.com>
Looks OK to me, modulo a couple of nits below.
With these addressed, feel free to add:
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
> +int mpt3sas_hwmon_register(struct MPT3SAS_ADAPTER *ioc)
> +{
> + struct device *parent = &ioc->pdev->dev;
> + struct mpt3sas_hwmon *h;
> + struct device *hwdev;
> + Mpi2ConfigReply_t mpi_reply;
> + Mpi2IOUnitPage7_t page;
> + int r;
> +
> + h = kzalloc_obj(*h);
> + if (!h)
> + return -ENOMEM;
> +
> + h->ioc = ioc;
maybe move this below together with the h->ioc_present initialization ?
There seem to be no point for this line to be alone here.
> +
> + r = mpt3sas_config_get_iounit_pg7(ioc, &mpi_reply, &page);
> + if (r) {
> + kfree(h);
> + return r;
> + }
You should test for the page being present first and then allocate h if it is.
That would be cleaner/simpler.
> +
> + h->ioc_present = page.IOCTemperatureUnits != MPI2_IOUNITPAGE7_IOC_TEMP_NOT_PRESENT;
> + h->board_present = page.BoardTemperatureUnits != MPI2_IOUNITPAGE7_BOARD_TEMP_NOT_PRESENT;
> +
> + /*
> + * A page where both *TemperatureUnits are NOT_PRESENT covers
> + * two cases: cards that genuinely lack sensors, and firmware
> + * errors that left the page zero-filled (the accessor mirrors
> + * _config_request() behaviour). Either way: skip registration.
> + */
> + if (!h->ioc_present && !h->board_present) {
> + kfree(h);
> + return 0;
> + }
> +
> + hwdev = hwmon_device_register_with_info(parent, "mpt3sas", h,
> + &mpt3sas_hwmon_chip_info,
> + NULL);
> + if (IS_ERR(hwdev)) {
> + kfree(h);
> + return PTR_ERR(hwdev);
> + }
> +
> + h->hwmon_dev = hwdev;
> + ioc->hwmon = h;
> + return 0;
> +}
--
Damien Le Moal
Western Digital Research
prev parent reply other threads:[~2026-06-30 0:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-13 2:38 [PATCH v4 0/2] scsi: mpt3sas: add hwmon support Louis Sautier
2026-06-13 2:38 ` [PATCH v4 1/2] scsi: mpt3sas: add IO Unit Page 7 config accessor Louis Sautier
2026-06-13 2:45 ` sashiko-bot
2026-06-13 2:38 ` [PATCH v4 2/2] scsi: mpt3sas: add hwmon support Louis Sautier
2026-06-13 2:47 ` sashiko-bot
2026-06-30 0:28 ` Damien Le Moal [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=aeb83cdb-616e-49b8-a791-3748dae60133@kernel.org \
--to=dlemoal@kernel.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=MPT-FusionLinux.pdl@broadcom.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=martin.petersen@oracle.com \
--cc=ranjan.kumar@broadcom.com \
--cc=sathya.prakash@broadcom.com \
--cc=sautier.louis@gmail.com \
--cc=sreekanth.reddy@broadcom.com \
--cc=suganath-prabu.subramani@broadcom.com \
/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.