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] [thread-next>] [day] [month] [year] [list]

Message-ID: <e9f9e1b0-4cd7-4d6c-a7b9-25ea0e6e774a@vaisala.com>
Date: Tue, 3 Feb 2026 11:50:45 +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

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?

br,
Tomas



> 
> 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);
> 
> 	...
> }
> 
>