Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 31/01/2026 22:30, David Lechner wrote:
> On 1/30/26 3:16 AM, Tomas Melin wrote:
>> Not all backends support the full set of capabilities provided by the
>> industrialio-backend framework. Capability bits can be used in frontends
>> and backends for checking for a certain feature set, or if using
>> related functions can be expected to fail.
>>
>> Capability bits should be set by a compatible backend and provided when
>> registering the backend.
>>
> 
> ...
> 
>> +/**
>> + * enum iio_backend_capabilities - Backend capabilities
>> + * Backend capabilities can be used by frontends to check if a given
>> + * functionality is supported by the backend. This is useful for frontend
>> + * devices which are expected to work with alternative backend
>> + * implementations. Capabilities are loosely coupled with operations,
>> + * meaning that a capability requires certain operations to be implemented
>> + * by the backend. A capability might be mapped to a single operation or
>> + * multiple operations.
> 
> It would be helpful to list these operations explicitly for each
> enum member.

This has been discussed, the mapping might depend on the use case, i.e.
the combination of backend-frontend. For example the calibration might
be implemented in several ways depending on the device. Writing out the
mapping here would create problems for that kind of situations.
> 
>> + *
>> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
>> + * calibration. Calibration procedure is device specific.
>> + * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering.
> 
> I assume this means it supports devm_iio_backend_request_buffer()?
> 
> In IIO, we usually say "buffer" and rarely "buffering" so this name and
> description is a bit confusing to me.

Sure, would this mean that name and comment should be?
IIO_BACKEND_CAP_BUFFER: Backend has support for buffers

> 
>> + * @IIO_BACKEND_CAP_ALWAYS_ON: Backend does not need to be explicitly
>> + * enabled/disabled. It is always on.
> 
> Do we actually need this one? Alternative could be, for example:
> 
> int iio_backend_enable(struct iio_backend *back)
> {
> 	int ret;
> 
> 	ret = iio_backend_op_call(back, enable);
> 	
> 	return ret == -EOPNOTSUPP ? 0 : ret;
> }
> 
> Or make a iio_backend_optional_op_call() macro.
> 
> Or if there is some other nuance where this capability makes a
> difference, it should be explained in more detail.
One version in this series had that kind of approach where a single
capability mapping instead was shorted to check for EOPNOTSUPP, but it
was deemed better to have capability for everything needed and not in a
mixed fashion.


Thanks,
Tomas

> 
> 
>> + */
>> +enum iio_backend_capabilities {
> 
> Documenting members like this works too (saves a bit of cross-referencing).
> 
> 	/** @IIO_BACKEND_CAP_CALIBRATION: ... */
>> +	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
>> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
>> +	IIO_BACKEND_CAP_ALWAYS_ON = BIT(2),
>> +};