linux-kernel - Re: [PATCH v3 0/4] iio: adc: ad9467: Support alternative backends

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: <97468316-776b-4318-83af-b20a4e99a570@vaisala.com>
Date: Tue, 20 Jan 2026 13:01:45 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: Nuno Sá <noname.nuno@...il.com>,
 Jonathan Cameron <jic23@...nel.org>
Cc: Michael Hennerich <Michael.Hennerich@...log.com>,
 Nuno Sa <nuno.sa@...log.com>, Lars-Peter Clausen <lars@...afoo.de>,
 David Lechner <dlechner@...libre.com>, Andy Shevchenko <andy@...nel.org>,
 Olivier Moysan <olivier.moysan@...s.st.com>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/4] iio: adc: ad9467: Support alternative backends

Hi,

On 18/01/2026 11:21, Nuno Sá wrote:
> On Fri, 2026-01-16 at 18:37 +0000, Jonathan Cameron wrote:
>> On Fri, 16 Jan 2026 13:31:39 +0000
>> Nuno Sá <noname.nuno@...il.com> wrote:
>>
>>> On Thu, 2026-01-15 at 15:30 +0200, Tomas Melin wrote:

>>>>> What I have in mind would be really to do the same as regulators do. If you
>>>>> call
>>>>> regulator_get() then the consumer really assumes a regulator must exist. But
>>>>> if it
>>>>> is something the kernel does not control we get a dummy one with very limited
>>>>> functionality/stubs. If you call regulator_get_optional(), then the regulator
>>>>> is
>>>>> really optional and might not physically exist. Seems very similar to what
>>>>> you have.  
>>>>
>>>> There could perhaps be use for a backend like this too. Is the idea such
>>>> that one would still need to define a "iio-backend-simple" node or such
>>>> to device tree which would then provide the backend link and compatible?
>>>>   
>>>
>>> My idea would be to automatically define one if we fail to find it. Naturally if
>>> we
>>> ever add an optional() get the dummy could not be added. See how regulator_get()
>>> handles it. That's basically what I have in mind.
>>>
>> It's an interesting idea, but I'd like some input from DT folk on this.
>> The fake regulators thing is kind of legacy from lots of drivers gaining the
>> power handling later and it being boring / too late to add all the fixed regs
>> to DT.  This is a much less common case and I find it a little unlikely there
>> is nothing useful to know about where the data is going - so how useful
>> is an autocreated backend?
>>
> 
> Not really that useful. This was just something I thought of to have the full usecase
> supported in Linux. But, if we can add an explicit fixed/dummy (whatever name fits
> best) backend with a proper compatible that would be preferable, yes.

For now I think we should be okay without a dummy backend. Once the
capability feature is accepted this will be enough for current needs.
The capabilites will bring in a lot of flexibility as to what needs to
be implemented and not in the backend. In my case I can register a
backend from a driver that is not exactly that, but provides related
functionality.

BR,
Tomas


> 
> - Nuno Sá
>