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

[Jonathan Cameron]

On Thu, 26 Feb 2026 17:57:53 +0200
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> 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.  
>