From: Andreas Kemnade <andreas@kemnade.info>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Mark Brown <broonie@kernel.org>,
jdelvare@suse.com, lgirdwood@gmail.com,
linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
Alistair Francis <alistair@alistair23.me>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
Jonathan Cameron <jic23@kernel.org>
Subject: In-kernel hwmon read: (was: Re: [PATCH RFC 1/2] hwmon: (sy7636a) fix races during probe of mfd subdevices)
Date: Thu, 22 Jan 2026 15:23:06 +0100 [thread overview]
Message-ID: <20260122152306.6211995e@kemnade.info> (raw)
In-Reply-To: <e6c8f022-ebfc-459c-806b-f75618f65916@roeck-us.net>
On Wed, 24 Sep 2025 12:16:14 -0700
Guenter Roeck <linux@roeck-us.net> wrote:
> > But what is the hwmon equivalent for
> > devm_fwnode_iio_channel_get_by_name() + iio_read_channel_processed()?
> >
>
> Assuming you refer to the exported functions for in-kernel use, so far no one has
> expressed a need for it. The best solution would probably be a hwmon->iio bridge,
> or equivalent functions could be implemented and exported.
So first analyzing the need of such an interface. I think
there is a need for such interface. The need just gets masked by some hacks
to be able to divert to other interfaces.
There is out-of-tree waiting to be upstreamed:
- rockchip_ebc driver: Display on PineNote, uses iio_read_chanel_processed()
in combination with an out-of-tree iio temperature
driver
- mxc_epdc_drm driver: Display on Kobo/Tolino ebook readers, uses
thermal_zone_get_temp() now.
In tree, there is:
- drivers/gpu/drm/tiny/repaper.c
in combination with
Documentation/devicetree/bindings/display/repaper.txt
Code excerpt:
if (!device_property_read_string(dev, "pervasive,thermal-zone",
&thermal_zone)) {
epd->thermal = thermal_zone_get_zone_by_name(thermal_zone);
and thermal_zone_get_temp() to tune refreshes according to panel temperature.
The example in the binding is:
display_temp: lm75@48 {
compatible = "lm75b";
reg = <0x48>;
#thermal-sensor-cells = <0>;
};
thermal-zones {
display {
polling-delay-passive = <0>;
polling-delay = <0>;
thermal-sensors = <&display_temp>;
};
};
[...]
pervasive,thermal-zone = "display";
I would prefer to be able to use e.g. pervasive,temperature-sensor = <&display_temp>;
or maybe <&display_temp 0> if there are multiple sensors in the same chip.
so that dtc will tell me when there is a typo and avoid the thermal
zone layer
So what are the options:
a) provide similar logic like iio/inkern.c for hwmon usage.
b) automatically add iio channels during hwmon registration.
looking at the iio_hwmon bridge we already have, it depends on
iio/inkern.c so for a hwmon_iio bridge we need a) or b) anyways,
so I think a separate bridge device/driver has no advantages.
And having a devicetree node for the bridge would be bad because
we are then describing linux implementation details instead of
the actual hardware in the devicetree.
Regards,
Andreas
next prev parent reply other threads:[~2026-01-22 14:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-20 11:43 [PATCH 0/2] hmwon: (sy7636a) fix regulator handling Andreas Kemnade
2025-09-20 11:43 ` [PATCH RFC 1/2] hwmon: (sy7636a) fix races during probe of mfd subdevices Andreas Kemnade
2025-09-20 19:58 ` Mark Brown
2025-09-20 21:33 ` Andreas Kemnade
2025-09-20 22:18 ` Mark Brown
2025-09-21 16:35 ` Andreas Kemnade
2025-09-24 7:00 ` Andreas Kemnade
2025-09-24 7:17 ` Guenter Roeck
2025-09-24 17:53 ` Andreas Kemnade
2025-09-24 19:16 ` Guenter Roeck
2025-09-27 18:39 ` Jonathan Cameron
2025-10-27 20:12 ` Andreas Kemnade
2026-01-22 14:23 ` Andreas Kemnade [this message]
2026-01-31 18:42 ` In-kernel hwmon read: (was: Re: [PATCH RFC 1/2] hwmon: (sy7636a) fix races during probe of mfd subdevices) Jonathan Cameron
2026-02-01 16:29 ` In-kernel hwmon read: Guenter Roeck
2025-09-24 8:44 ` [PATCH RFC 1/2] hwmon: (sy7636a) fix races during probe of mfd subdevices Mark Brown
2025-10-27 11:30 ` Andreas Kemnade
2025-09-20 11:43 ` [PATCH 2/2] hwmon: (sy7636a) enable regulator only if needed Andreas Kemnade
2025-09-24 16:06 ` Guenter Roeck
2025-09-24 20:40 ` Andreas Kemnade
2025-09-24 21:06 ` Guenter Roeck
2025-09-24 21:58 ` Andreas Kemnade
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=20260122152306.6211995e@kemnade.info \
--to=andreas@kemnade.info \
--cc=alistair@alistair23.me \
--cc=broonie@kernel.org \
--cc=jdelvare@suse.com \
--cc=jic23@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/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