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

[Francesco Lavra <flavra@baylibre.com>]

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.