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

David Lechner
2026-02-02T15:50:22Z

On 2/2/26 7:04 AM, Tomas Melin wrote:
> 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.
>

Ah, this is what Jonathan mentioned before about this really being a
restriction rather than a capability.

Perhaps we should have a separate restrictions/quirks flag? If the flag
means "do not enable during probe" then a better name would be
*_DO_NOT_ENABLE_AT_PROBE.

And I agree with Nuno that if the backend can be enabled/disabled later
(after probe), it should still be managed through the frontend driver.
There should be no usespace access directly to the backend without going
through the frontend.

In this case, I guess we could call it a capability still. But I would
call it something like *_DEFERABLE_ENABLE or something like that. The
logic would be something like:

int probe() {
...

if (_DEFERABLE_ENABLE) {
/* Basically equivalent to buffer enable, but there is no buffer. */
register_userspace_enable_attribute();
else
iio_backend_enable(backend);

...
}