Re: [PATCH v6 6/7] iio: ABI: Add custom data type

[Andy Shevchenko]

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