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

[Tomas Melin]

Hi,

On 02/02/2026 14:40, Nuno Sá wrote:
> On Mon, 2026-02-02 at 13:08 +0200, Tomas Melin wrote:
>> Hi,
>>
>> On 02/02/2026 12:28, Nuno Sá wrote:
>>> On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:
>>
>>>>
>>>> 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;
>>>> }
>>>
>>> I would prefer not to assume we can ignore the backend not supporting
>>> the call. It opens up the question for other operations.
>>>
>>> My preferred way for this kind of fundamental operation (enabling/disabling)
>>> would be to check with DT maintainers if we could have some kind of fixed-backend
>>> (fixed in the sense the HW is present but not controlled by Linux) dummy device that
>>> with implement a no-OP enable/disable().
>>
>> There is also use cases for the always_on cap with a configurable
>> non-dummy backend. Some applications are such that the driver should
>> leave the enabling/disabling up to the user space consuming the data.
>> For this case it's great to have the frontend leave the backend enable
>> alone using this capability.
>>
> 
> I would argue the above would be something to take care at the frontend level. The way
> I see it, the always_on cap is pretty much saying that we can't really control the on/off state
> of the backing device and we just assume it's on. 
> 
> If we can control it but we need it always on (for some specific usecase), I would say that should
> be handled at the frontend and just enable the backend once. Also note that as of now, I think all
> of the users (or most at least) we have just enable the backend during probe and leave it on until
> we unbind the device.

Yes, this is debatable. It's not necessarily always on, but should not
be enabled/touched by the frontend during probe.
But anyways, having a capability that says if the enable/disable feature
is available, is in any case useful and what I was planning on
leveraging in my use case.
Fundamentally, with the capabilites as now proposed, it is possible to
select what features of the ad9467 are available, in addition to the
basic requirements.

The ALWAYS_ON capability could be inverted, like CAP_HAS_ENABLE_DISABLE,
but to me, the ALWAYS_ON naming still seems the better option.

Thanks,
Tomas


> 
> - Nuno Sá
> 
>