This type is used when the data received from or sent to a device cannot be
identified with a standard type and must be processed by custom userspace.
Any driver using the custom type must provide a driver-specific document
that explains what the data represents and how it is to be interpreted by
userspace.
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
---
Documentation/ABI/testing/sysfs-bus-iio | 19 +++++++++++++++++++
drivers/iio/industrialio-core.c | 1 +
include/uapi/linux/iio/types.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 61961bca4dce..2e45e54f54eb 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -450,6 +450,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_offset
What: /sys/bus/iio/devices/iio:deviceX/in_rot_offset
What: /sys/bus/iio/devices/iio:deviceX/in_angl_offset
What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_offset
+What: /sys/bus/iio/devices/iio:deviceX/in_custom_offset
+What: /sys/bus/iio/devices/iio:deviceX/in_customY_offset
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -507,6 +509,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_scale
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_custom_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_customY_scale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -1486,6 +1490,8 @@ What: /sys/.../iio:deviceX/bufferY/in_pressureY_en
What: /sys/.../iio:deviceX/bufferY/in_pressure_en
What: /sys/.../iio:deviceX/bufferY/in_rot_quaternion_en
What: /sys/.../iio:deviceX/bufferY/in_proximity_en
+What: /sys/.../iio:deviceX/bufferY/in_custom_en
+What: /sys/.../iio:deviceX/bufferY/in_customZ_en
KernelVersion: 5.11
Contact: linux-iio@vger.kernel.org
Description:
@@ -1505,6 +1511,8 @@ What: /sys/.../iio:deviceX/bufferY/in_pressureY_type
What: /sys/.../iio:deviceX/bufferY/in_pressure_type
What: /sys/.../iio:deviceX/bufferY/in_rot_quaternion_type
What: /sys/.../iio:deviceX/bufferY/in_proximity_type
+What: /sys/.../iio:deviceX/bufferY/in_custom_type
+What: /sys/.../iio:deviceX/bufferY/in_customZ_type
KernelVersion: 5.11
Contact: linux-iio@vger.kernel.org
Description:
@@ -1566,6 +1574,8 @@ What: /sys/.../iio:deviceX/bufferY/in_pressureY_index
What: /sys/.../iio:deviceX/bufferY/in_pressure_index
What: /sys/.../iio:deviceX/bufferY/in_rot_quaternion_index
What: /sys/.../iio:deviceX/bufferY/in_proximity_index
+What: /sys/.../iio:deviceX/bufferY/in_custom_index
+What: /sys/.../iio:deviceX/bufferY/in_customZ_index
KernelVersion: 5.11
Contact: linux-iio@vger.kernel.org
Description:
@@ -2393,6 +2403,15 @@ Description:
The x and y light color coordinate on the CIE 1931 chromaticity
diagram.
+What: /sys/bus/iio/devices/iio:deviceX/in_custom_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_customY_raw
+KernelVersion: 7.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Custom input value, whose type is driver-specific and is described
+ in a separate document. It can have a modifier Y, in which case it
+ is a measuremement from channel Y.
+
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_mag_either_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_mag_rising_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_thresh_falling_label
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 22eefd048ba9..dd179e3b0fb7 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -98,6 +98,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CHROMATICITY] = "chromaticity",
[IIO_ATTENTION] = "attention",
[IIO_ALTCURRENT] = "altcurrent",
+ [IIO_CUSTOM] = "custom"
};
static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 6d269b844271..47fefcdd693c 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -53,6 +53,7 @@ enum iio_chan_type {
IIO_CHROMATICITY,
IIO_ATTENTION,
IIO_ALTCURRENT,
+ IIO_CUSTOM
};
enum iio_modifier {
--
2.39.5On Wed, Feb 25, 2026 at 11:18:06AM +0100, Francesco Lavra wrote:
> This type is used when the data received from or sent to a device cannot be
> identified with a standard type and must be processed by custom userspace.
> Any driver using the custom type must provide a driver-specific document
> that explains what the data represents and how it is to be interpreted by
> userspace.
This rises the same Q as for other firmware-hidden algos, et cetera: How
can we prevent the kernel from being just a simple proxy between HW and
the userspace? What would be the point of having the "driver" in the kernel
space?
...
> static const char * const iio_chan_type_name_spec[] = {
> [IIO_CHROMATICITY] = "chromaticity",
> [IIO_ATTENTION] = "attention",
> [IIO_ALTCURRENT] = "altcurrent",
> + [IIO_CUSTOM] = "custom"
No more channel types after this? Why?
> };
...
> enum iio_chan_type {
> IIO_CHROMATICITY,
> IIO_ATTENTION,
> IIO_ALTCURRENT,
> + IIO_CUSTOM
Ditto.
> };
--
With Best Regards,
Andy Shevchenko
On 2/25/26 5:43 AM, Andy Shevchenko wrote: > On Wed, Feb 25, 2026 at 11:18:06AM +0100, Francesco Lavra wrote: >> This type is used when the data received from or sent to a device cannot be >> identified with a standard type and must be processed by custom userspace. >> Any driver using the custom type must provide a driver-specific document >> that explains what the data represents and how it is to be interpreted by >> userspace. > > This rises the same Q as for other firmware-hidden algos, et cetera: How > can we prevent the kernel from being just a simple proxy between HW and > the userspace? What would be the point of having the "driver" in the kernel > space? > I tend to agree that this opens the door for misuse or an excuse to not make the effort to develop something more generally useful on future drivers. For this patch series, could we still use IIO_ROT and introduce a new IIO_MOD_PARTIAL_QUATERNION that is defined according to the description in the documentation patch in this series? This may be the only driver that ever uses it, but it is still clearly defined. Or perhaps we could even say that if a IIO_MOD_QUATERNION has .repeat = 3 instead of .repeat = 4, then it should be interpreted this way?
On Wed, Feb 25, 2026 at 03:27:55PM -0600, David Lechner wrote: > On 2/25/26 5:43 AM, Andy Shevchenko wrote: > > On Wed, Feb 25, 2026 at 11:18:06AM +0100, Francesco Lavra wrote: > >> This type is used when the data received from or sent to a device cannot be > >> identified with a standard type and must be processed by custom userspace. > >> Any driver using the custom type must provide a driver-specific document > >> that explains what the data represents and how it is to be interpreted by > >> userspace. > > > > This rises the same Q as for other firmware-hidden algos, et cetera: How > > can we prevent the kernel from being just a simple proxy between HW and > > the userspace? What would be the point of having the "driver" in the kernel > > space? > > I tend to agree that this opens the door for misuse or an excuse to not > make the effort to develop something more generally useful on future drivers. > > For this patch series, could we still use IIO_ROT and introduce a > new IIO_MOD_PARTIAL_QUATERNION that is defined according to the > description in the documentation patch in this series? This may be > the only driver that ever uses it, but it is still clearly defined. > > Or perhaps we could even say that if a IIO_MOD_QUATERNION has > .repeat = 3 instead of .repeat = 4, then it should be interpreted > this way? Not sure about the latter, but something explicit like IIO_MOD_PARTIAL_QUATERNION sounds good to me. -- With Best Regards, Andy Shevchenko
On Thu, 2026-02-26 at 11:21 +0200, Andy Shevchenko wrote: > On Wed, Feb 25, 2026 at 03:27:55PM -0600, David Lechner wrote: > > On 2/25/26 5:43 AM, Andy Shevchenko wrote: > > > On Wed, Feb 25, 2026 at 11:18:06AM +0100, Francesco Lavra wrote: > > > > This type is used when the data received from or sent to a device > > > > cannot be > > > > identified with a standard type and must be processed by custom > > > > userspace. > > > > Any driver using the custom type must provide a driver-specific > > > > document > > > > that explains what the data represents and how it is to be > > > > interpreted by > > > > userspace. > > > > > > This rises the same Q as for other firmware-hidden algos, et cetera: > > > How > > > can we prevent the kernel from being just a simple proxy between HW > > > and > > > the userspace? What would be the point of having the "driver" in the > > > kernel > > > space? > > > > I tend to agree that this opens the door for misuse or an excuse to not > > make the effort to develop something more generally useful on future > > drivers. > > > > For this patch series, could we still use IIO_ROT and introduce a > > new IIO_MOD_PARTIAL_QUATERNION that is defined according to the > > description in the documentation patch in this series? This may be > > the only driver that ever uses it, but it is still clearly defined. > > > > Or perhaps we could even say that if a IIO_MOD_QUATERNION has > > .repeat = 3 instead of .repeat = 4, then it should be interpreted > > this way? > > Not sure about the latter, but something explicit like > IIO_MOD_PARTIAL_QUATERNION sounds good to me. Another option could be having a custom iio_modifier instead of a custom iio_chan_type. I think this would address the concern of drivers being just a proxy between hardware and userspace. A custom modifier would be used when the data representation for a given channel is too exotic to warrant a generic iio_modifier enum value (but would still need to be documented so that userspace can make use of it). I can imagine a generic userspace application that interfaces with (in this case) rotation sensors (i.e. looks for IIO_ROT channels) and can support not only "standard" rotation data types (yaw, pitch, roll, quaternion, etc) but also "manufacturer-specific" types. We could even think about allowing more than one custom modifier (e.g. everything >= IIO_MOD_CUSTOM is a custom modifier) so that a sensor can have its "manufacturer-specific" data in multiple separate channels; and of course each such custom modifier would have to be described in a per-driver doc.
On Thu, Feb 26, 2026 at 04:30:27PM +0100, Francesco Lavra wrote: > On Thu, 2026-02-26 at 11:21 +0200, Andy Shevchenko wrote: > > On Wed, Feb 25, 2026 at 03:27:55PM -0600, David Lechner wrote: ... > > Not sure about the latter, but something explicit like > > IIO_MOD_PARTIAL_QUATERNION sounds good to me. > > Another option could be having a custom iio_modifier instead of a custom > iio_chan_type. I think this would address the concern of drivers being just > a proxy between hardware and userspace. A custom modifier would be used > when the data representation for a given channel is too exotic to warrant a > generic iio_modifier enum value (but would still need to be documented so > that userspace can make use of it). > I can imagine a generic userspace application that interfaces with (in this > case) rotation sensors (i.e. looks for IIO_ROT channels) and can support > not only "standard" rotation data types (yaw, pitch, roll, quaternion, etc) > but also "manufacturer-specific" types. And I am against this. It will provoke a vendor to escape the standards, common libraries and other tools. If we need something which is too exotic, the driver should convert it to the standard one. This way we will support HW and won't require or allow some dirty tricks based on vendor-locked approaches. I'm talking from the experience on what vendors are doing or want to do IRL in other areas. One of the infamous example, is Broadcom Bluetooth used back in Nokia phones, the so called "driver" is useless completely in the kernel as it's just a proxy for the HW <--> userspace link. TL;DR: I'm in favour for anything that does not touch user space at all, or has explicit meanings. NAK for CUSTOM, manufactirer-specific, et cetera from me is warranted. > We could even think about allowing more than one custom modifier (e.g. > everything >= IIO_MOD_CUSTOM is a custom modifier) so that a sensor can > have its "manufacturer-specific" data in multiple separate channels; and of > course each such custom modifier would have to be described in a per-driver > doc. -- With Best Regards, Andy Shevchenko
On Thu, 26 Feb 2026 17:57:53 +0200 Andy Shevchenko <andriy.shevchenko@intel.com> wrote: > On Thu, Feb 26, 2026 at 04:30:27PM +0100, Francesco Lavra wrote: > > On Thu, 2026-02-26 at 11:21 +0200, Andy Shevchenko wrote: > > > On Wed, Feb 25, 2026 at 03:27:55PM -0600, David Lechner wrote: > > ... > > > > Not sure about the latter, but something explicit like > > > IIO_MOD_PARTIAL_QUATERNION sounds good to me. > > > > Another option could be having a custom iio_modifier instead of a custom > > iio_chan_type. I think this would address the concern of drivers being just > > a proxy between hardware and userspace. A custom modifier would be used > > when the data representation for a given channel is too exotic to warrant a > > generic iio_modifier enum value (but would still need to be documented so > > that userspace can make use of it). > > I can imagine a generic userspace application that interfaces with (in this > > case) rotation sensors (i.e. looks for IIO_ROT channels) and can support > > not only "standard" rotation data types (yaw, pitch, roll, quaternion, etc) > > but also "manufacturer-specific" types. > > And I am against this. It will provoke a vendor to escape the standards, > common libraries and other tools. If we need something which is too exotic, > the driver should convert it to the standard one. This way we will support > HW and won't require or allow some dirty tricks based on vendor-locked > approaches. > > I'm talking from the experience on what vendors are doing or want to do > IRL in other areas. One of the infamous example, is Broadcom Bluetooth > used back in Nokia phones, the so called "driver" is useless completely > in the kernel as it's just a proxy for the HW <--> userspace link. > > TL;DR: I'm in favour for anything that does not touch user space at all, > or has explicit meanings. NAK for CUSTOM, manufactirer-specific, et cetera > from me is warranted. The representation here is to my mind 'odd' enough that I'm be surprised if another manufacturer ever used it. Maybe I'm wrong though, I'm out of touch with IMUs these days and defacto standards do arise sometimes. I'm not sure we can paper over it in the kernel without going to floating point maths and I don't want to start a precedence for doing that. If anyone can figure out an efficient integer solution, then that would be great. I'm not against a specific modifier, but that space is only so big so I don't want to end up running out of space. Maybe this is a case for a low impact experiment: We add a specific modifier for this format - with full documentation (and userspace code in the tools that come with the kernel) and see if that opens the flood gates to requests for other custom channels. It's worth noting I was relaxed on this once before for pulse oximeters (the things under drivers/iio/health) because for various odd historical reasons I happened to know a bit about the maths needed to get data from those and there was a plausible channel type for the channels (as they were always light sensing, be it against a light source that was varying). That one didn't lead to a deluge but then it was more a case of allowing a minor abuse of the ABI than adding an official custom path. Also worth noting this sensor provides all of the real channels in normal ABI compliant fashion, it's just this odd derived channel that is tripping us up. Jonathan > > > We could even think about allowing more than one custom modifier (e.g. > > everything >= IIO_MOD_CUSTOM is a custom modifier) so that a sensor can > > have its "manufacturer-specific" data in multiple separate channels; and of > > course each such custom modifier would have to be described in a per-driver > > doc. >
© 2016 - 2026 Red Hat, Inc.