From: Jihong Min <hurryman2212@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>, linux-hwmon@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
linux-api@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 0/5] hwmon: Introduce uhwmon for userspace implementations
Date: Sat, 10 Oct 2026 00:38:39 +0900 [thread overview]
Message-ID: <cover.1791531025.git.hurryman2212@gmail.com> (raw)
This series introduces uhwmon, a generic hwmon interface connecting
userspace implementations to the kernel. It exposes hwmon sensor and
attribute definitions to userspace through <linux/hwmon.h>, allowing
userspace drivers to create standard hwmon sysfs attributes. uhwmon
forwards reads and writes through /dev/uhwmon. The hwmon core handles
numeric text conversion and newlines for kernel and userspace drivers.
The series also adds kernel documentation explaining the interface and
how to use its UAPI.
In the October 2024 IT87 discussion [1], a read-only hwmon driver
configured from userspace was suggested for chips without datasheets and
for testing new chips. Guenter Roeck said he would need proposal
details, but questioned whether the hwmon sysfs ABI justified new kernel
infrastructure: userspace drivers would still need hardware knowledge
and access. He suggested an API between those drivers and libsensors as
an alternative.
But I see practical value in retaining hwmon: the use case below already
works with unmodified sensors through its existing hwmon interface. A
common bridge can similarly let other daemons expose measurements
without adding a new input path to existing hwmon applications, reducing
duplicated integration work. The idea is conceptually similar to
dummy_hcd with a userspace gadget interface.
uhwmon's goal is to let applications using the standard hwmon interface
access sensors without mainline drivers, without adding per-device
support to userspace libraries or building and loading separate DKMS
modules. In theory, projects such as wireview-hwmon [2] could replace
their device-specific DKMS module with uhwmon and adapt their daemon to
use it. My current use case is bridging the Tapo API [3] to hwmon, using
a TAPO P110M smart plug to measure my system's power draw at the wall in
place of an ACPI power meter. I have tested this setup in an Ubuntu VM,
including live readings, daemon disconnect and recovery, and reboot startup.
[1] https://lkml.iu.edu/2410.2/11841.html
[2] https://github.com/emaspa/wireview-hwmon
[3] https://github.com/mihai-dinculescu/tapo
Jihong Min (5):
hwmon: Export sensor and attribute definitions to userspace
hwmon: Expose attribute validation and string helpers
hwmon: Add a generic interface for userspace implementations
hwmon: Reject truncated attribute names
docs: hwmon: Document the uhwmon userspace interface
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/uhwmon.rst | 141 +++++
Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
MAINTAINERS | 2 +
drivers/hwmon/Kconfig | 9 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/hwmon.c | 38 +-
drivers/hwmon/uhwmon.c | 641 +++++++++++++++++++++
include/linux/hwmon.h | 356 +-----------
include/uapi/linux/hwmon.h | 372 ++++++++++++
include/uapi/linux/uhwmon.h | 64 ++
11 files changed, 1267 insertions(+), 359 deletions(-)
create mode 100644 Documentation/hwmon/uhwmon.rst
create mode 100644 drivers/hwmon/uhwmon.c
create mode 100644 include/uapi/linux/hwmon.h
create mode 100644 include/uapi/linux/uhwmon.h
base-commit: 7b63ef2d55f24519e7e9e5f4d15dbea03f126e40
Sincerely,
Jihong Min
next reply other threads:[~2026-10-09 15:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 15:38 Jihong Min [this message]
2026-10-09 15:38 ` [PATCH 1/5] hwmon: Export sensor and attribute definitions to userspace Jihong Min
2026-10-09 15:38 ` [PATCH 2/5] hwmon: Expose attribute validation and string helpers Jihong Min
2026-10-09 15:38 ` [PATCH 3/5] hwmon: Add a generic interface for userspace implementations Jihong Min
2026-10-09 15:38 ` [PATCH 4/5] hwmon: Reject truncated attribute names Jihong Min
2026-10-09 15:38 ` [PATCH 5/5] docs: hwmon: Document the uhwmon userspace interface Jihong Min
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=cover.1791531025.git.hurryman2212@gmail.com \
--to=hurryman2212@gmail.com \
--cc=corbet@lwn.net \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®