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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0a3eacf2-a68a-48e1-8b88-10dfe4f0ab88@vaisala.com>
Date: Wed, 4 Feb 2026 13:15:36 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: David Lechner <dlechner@...libre.com>, Nuno Sá
 <noname.nuno@...il.com>, Michael Hennerich <Michael.Hennerich@...log.com>,
 Nuno Sa <nuno.sa@...log.com>, Lars-Peter Clausen <lars@...afoo.de>,
 Jonathan Cameron <jic23@...nel.org>, Andy Shevchenko <andy@...nel.org>,
 Olivier Moysan <olivier.moysan@...s.st.com>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/4] iio: industrialio-backend: support backend
 capabilities

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



> 
>