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

Tomas Melin
2026-02-04T11:16:45Z

On 04/02/2026 03:07, David Lechner wrote:
> On 2/3/26 3:50 AM, Tomas Melin wrote:
>> Hi,
>>
>> On 02/02/2026 17:50, David Lechner wrote:
>>> 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.
>>
>> Thanks for the input, that use case is slightly different from normal
>> usage, let's keep it in mind if actually required. For now, the option
>> to just leave the enable/disable alone is what would help to solve
>> smooth integration with this device for me.
>>
>> ALWAYS_ON does not seem to get much votes here, but how about calling it
>> something like IIO_BACKEND_CAP_AUTO_ENABLE or
>> IIO_BACKEND_CAP_HAS_ENABLE_DISABLE?
>>
> IIO_BACKEND_CAP_HAS_ENABLE_DISABLE seems the most sensible given the
> way it is used in the ad9467 patch. Although IIO_BACKEND_CAP_ENABLE_DISABLE
> would be more consistent with the other flags being added since they
> don't say _HAS_.
>
> Probably IIO_BACKEND_CAP_ENABLE is enough to imply both if we want
> to keep it shorter.

I would agree that IIO_BACKEND_CAP_ENABLE should be clear enough. I'll
use this in the next version.

thanks,
Tomas

>
>