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: <c9a5b1b3-760e-4d55-b058-e461507fcad0@baylibre.com>
Date: Tue, 3 Feb 2026 19:07:35 -0600
From: David Lechner <dlechner@...libre.com>
To: Tomas Melin <tomas.melin@...sala.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 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.