To facilitate backends with different set of features, add support
for defining capabilites provided by the backend. These capabilites
typically extend beyond a single operation and are therefore not
directly linked to if a single function call is implemented or not.
Furthermore, the capabilites determine if a certain set of operations
should be attempted, or skipped by the frontend. This way
the frontend driver can work with a minimalistic set of features and
still have the device in fully functional state.

Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
Changes in v3:
- Reduce set of capabilities to only include calibration. The other
  ones propsed in V2 can be seen as subset of calibration, or single
  operation failing with opnotsupported
- Rename backends checking function
- Relocate caps field inside backend struct (pahole)
- Add kernel-docs
- Add capabilites for exisiting backend variants
- Link to v2: https://lore.kernel.org/r/20260113-b4-ad9467-optional-backend-v2-0-0a27e7e72f41@vaisala.com

Changes in v2:
- Added industrialio-backend capabilities feature
- Removed acceptance for fully optional backend, instead require atleast
  minimalistic backend to exist
- Switched to FIELD_MODIFY()
- Fixed kernel test robot reported failure for missing bitfield.h
- Link to v1: https://lore.kernel.org/r/20251216-b4-ad9467-optional-backend-v1-0-83e61531ef4d@vaisala.com

---
Tomas Melin (4):
      iio: adc: ad9467: include two's complement in default mode
      iio: industrialio-backend: support backend capabilities
      iio: adc: adi-axi-adc: define supported iio-backend capabilities
      iio: adc: ad9467: check for backend capabilities

 drivers/iio/adc/ad9467.c           | 44 ++++++++++++++++++++++++++++++--------
 drivers/iio/adc/adi-axi-adc.c      |  2 ++
 drivers/iio/industrialio-backend.c | 17 +++++++++++++++
 include/linux/iio/backend.h        | 17 +++++++++++++++
 4 files changed, 71 insertions(+), 9 deletions(-)
---
base-commit: a7b10f0963c651a6406d958a5f64b9c5594f84da
change-id: 20251215-b4-ad9467-optional-backend-23f1099ee4d7

Best regards,
-- 
Tomas Melin <tomas.melin@vaisala.com>

On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> To facilitate backends with different set of features, add support
> for defining capabilites provided by the backend. These capabilites
> typically extend beyond a single operation and are therefore not
> directly linked to if a single function call is implemented or not.
> Furthermore, the capabilites determine if a certain set of operations
> should be attempted, or skipped by the frontend. This way
> the frontend driver can work with a minimalistic set of features and
> still have the device in fully functional state.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---

Hi Tomas,

> Changes in v3:
> - Reduce set of capabilities to only include calibration. The other
>   ones propsed in V2 can be seen as subset of calibration, or single
>   operation failing with opnotsupported

As stated in my patch comment. Using opnotsupported for buffers defeats
the CAPS idea.


But more importantly, how are your usecase supposed to work with this
series? I'm not seeing any new backend being added as part of the series.
Point is, if we are adding all of this, I would expect your usecase to
have fully upstream support. If I'm not missing nothing, we would at least
need a dummy backend providing stubs for enable()/disable()

- Nuno Sá

Hi Nuno,

On 14/01/2026 15:32, Nuno Sá wrote:
> On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
>> To facilitate backends with different set of features, add support
>> for defining capabilites provided by the backend. These capabilites
>> typically extend beyond a single operation and are therefore not
>> directly linked to if a single function call is implemented or not.
>> Furthermore, the capabilites determine if a certain set of operations
>> should be attempted, or skipped by the frontend. This way
>> the frontend driver can work with a minimalistic set of features and
>> still have the device in fully functional state.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
> 
> Hi Tomas,
> 
>> Changes in v3:
>> - Reduce set of capabilities to only include calibration. The other
>>   ones propsed in V2 can be seen as subset of calibration, or single
>>   operation failing with opnotsupported
> 
> As stated in my patch comment. Using opnotsupported for buffers defeats
> the CAPS idea.
Please check my other reply, to me adding cap for a 1:1 mapping of a
operation seems like duplicating the information. But of course, this
can be viewed from different angles and it is also possible to look at
it like that.

> 
> 
> But more importantly, how are your usecase supposed to work with this
> series? I'm not seeing any new backend being added as part of the series.
> Point is, if we are adding all of this, I would expect your usecase to
> have fully upstream support. If I'm not missing nothing, we would at least
> need a dummy backend providing stubs for enable()/disable()
My usecase adds simplistic backend support and registers to the
framework via an related driver. So that use case works with that
approach. I think it is better to assume there is always some entity
that can take on the role of being backend, rather than adding a dummy
backend. Adding the capabilities are defining role here, as having that
allows for customer integrations with backends that differ but are of no
interest for the mainline.

Thanks,
Tomas






> 
> - Nuno Sá

On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:
> Hi Nuno,
> 
> On 14/01/2026 15:32, Nuno Sá wrote:
> > On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> > > To facilitate backends with different set of features, add support
> > > for defining capabilites provided by the backend. These capabilites
> > > typically extend beyond a single operation and are therefore not
> > > directly linked to if a single function call is implemented or not.
> > > Furthermore, the capabilites determine if a certain set of operations
> > > should be attempted, or skipped by the frontend. This way
> > > the frontend driver can work with a minimalistic set of features and
> > > still have the device in fully functional state.
> > > 
> > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> > > ---
> > 
> > Hi Tomas,
> > 
> > > Changes in v3:
> > > - Reduce set of capabilities to only include calibration. The other
> > >   ones propsed in V2 can be seen as subset of calibration, or single
> > >   operation failing with opnotsupported
> > 
> > As stated in my patch comment. Using opnotsupported for buffers defeats
> > the CAPS idea.
> Please check my other reply, to me adding cap for a 1:1 mapping of a
> operation seems like duplicating the information. But of course, this
> can be viewed from different angles and it is also possible to look at
> it like that.
> 
> > 
> > 
> > But more importantly, how are your usecase supposed to work with this
> > series? I'm not seeing any new backend being added as part of the series.
> > Point is, if we are adding all of this, I would expect your usecase to
> > have fully upstream support. If I'm not missing nothing, we would at least
> > need a dummy backend providing stubs for enable()/disable()
> My usecase adds simplistic backend support and registers to the
> framework via an related driver. So that use case works with that
> approach. I think it is better to assume there is always some entity
> that can take on the role of being backend, rather than adding a dummy
> backend. Adding the capabilities are defining role here, as having that

Well, I would argue your backend is exactly that. A dummy one :)

> allows for customer integrations with backends that differ but are of no
> interest for the mainline.
> 

It would still be nice to have this usecase fully supported upstream 
(having a black box backend). 

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.

- Nuno Sá

Hi,

On 15/01/2026 14:04, Nuno Sá wrote:
> On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:
>> Hi Nuno,
>>
>> On 14/01/2026 15:32, Nuno Sá wrote:

>>>
>>> But more importantly, how are your usecase supposed to work with this
>>> series? I'm not seeing any new backend being added as part of the series.
>>> Point is, if we are adding all of this, I would expect your usecase to
>>> have fully upstream support. If I'm not missing nothing, we would at least
>>> need a dummy backend providing stubs for enable()/disable()
>> My usecase adds simplistic backend support and registers to the
>> framework via an related driver. So that use case works with that
>> approach. I think it is better to assume there is always some entity
>> that can take on the role of being backend, rather than adding a dummy
>> backend. Adding the capabilities are defining role here, as having that
> 
> Well, I would argue your backend is exactly that. A dummy one :)

It's kindof ;)  But on general level it handles the stuff a backend
needs to do, just does not have most of the operations or capabilities
available. OTOH having the backend defined means that if some of the
capabilites would be added, there is a natural place to add it.

> 
>> allows for customer integrations with backends that differ but are of no
>> interest for the mainline.
>>
> 
> It would still be nice to have this usecase fully supported upstream 
> (having a black box backend). 
> 
> 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?

Thanks,
Tomas

> 
> - Nuno Sá

On Thu, 2026-01-15 at 15:30 +0200, Tomas Melin wrote:
> Hi,
> 
> On 15/01/2026 14:04, Nuno Sá wrote:
> > On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:
> > > Hi Nuno,
> > > 
> > > On 14/01/2026 15:32, Nuno Sá wrote:
> 
> > > > 
> > > > But more importantly, how are your usecase supposed to work with this
> > > > series? I'm not seeing any new backend being added as part of the series.
> > > > Point is, if we are adding all of this, I would expect your usecase to
> > > > have fully upstream support. If I'm not missing nothing, we would at least
> > > > need a dummy backend providing stubs for enable()/disable()
> > > My usecase adds simplistic backend support and registers to the
> > > framework via an related driver. So that use case works with that
> > > approach. I think it is better to assume there is always some entity
> > > that can take on the role of being backend, rather than adding a dummy
> > > backend. Adding the capabilities are defining role here, as having that
> > 
> > Well, I would argue your backend is exactly that. A dummy one :)
> 
> It's kindof ;)  But on general level it handles the stuff a backend
> needs to do, just does not have most of the operations or capabilities
> available. OTOH having the backend defined means that if some of the
> capabilites would be added, there is a natural place to add it.
> 

But there's nothing you can control from Linux right?

> > 
> > > allows for customer integrations with backends that differ but are of no
> > > interest for the mainline.
> > > 
> > 
> > It would still be nice to have this usecase fully supported upstream 
> > (having a black box backend). 
> > 
> > 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.

- Nuno Sá

On Fri, 16 Jan 2026 13:31:39 +0000
Nuno Sá <noname.nuno@gmail.com> wrote:

> On Thu, 2026-01-15 at 15:30 +0200, Tomas Melin wrote:
> > Hi,
> > 
> > On 15/01/2026 14:04, Nuno Sá wrote:  
> > > On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:  
> > > > Hi Nuno,
> > > > 
> > > > On 14/01/2026 15:32, Nuno Sá wrote:  
> >   
> > > > > 
> > > > > But more importantly, how are your usecase supposed to work with this
> > > > > series? I'm not seeing any new backend being added as part of the series.
> > > > > Point is, if we are adding all of this, I would expect your usecase to
> > > > > have fully upstream support. If I'm not missing nothing, we would at least
> > > > > need a dummy backend providing stubs for enable()/disable()  
> > > > My usecase adds simplistic backend support and registers to the
> > > > framework via an related driver. So that use case works with that
> > > > approach. I think it is better to assume there is always some entity
> > > > that can take on the role of being backend, rather than adding a dummy
> > > > backend. Adding the capabilities are defining role here, as having that  
> > > 
> > > Well, I would argue your backend is exactly that. A dummy one :)  
> > 
> > It's kindof ;)  But on general level it handles the stuff a backend
> > needs to do, just does not have most of the operations or capabilities
> > available. OTOH having the backend defined means that if some of the
> > capabilites would be added, there is a natural place to add it.
> >   
> 
> But there's nothing you can control from Linux right?
> 
> > >   
> > > > allows for customer integrations with backends that differ but are of no
> > > > interest for the mainline.
> > > >   
> > > 
> > > It would still be nice to have this usecase fully supported upstream 
> > > (having a black box backend). 
> > > 
> > > 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?

Jonathan

> - Nuno Sá

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@gmail.com> wrote:
> 
> > On Thu, 2026-01-15 at 15:30 +0200, Tomas Melin wrote:
> > > Hi,
> > > 
> > > On 15/01/2026 14:04, Nuno Sá wrote:  
> > > > On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:  
> > > > > Hi Nuno,
> > > > > 
> > > > > On 14/01/2026 15:32, Nuno Sá wrote:  
> > >   
> > > > > > 
> > > > > > But more importantly, how are your usecase supposed to work with this
> > > > > > series? I'm not seeing any new backend being added as part of the series.
> > > > > > Point is, if we are adding all of this, I would expect your usecase to
> > > > > > have fully upstream support. If I'm not missing nothing, we would at
> > > > > > least
> > > > > > need a dummy backend providing stubs for enable()/disable()  
> > > > > My usecase adds simplistic backend support and registers to the
> > > > > framework via an related driver. So that use case works with that
> > > > > approach. I think it is better to assume there is always some entity
> > > > > that can take on the role of being backend, rather than adding a dummy
> > > > > backend. Adding the capabilities are defining role here, as having that  
> > > > 
> > > > Well, I would argue your backend is exactly that. A dummy one :)  
> > > 
> > > It's kindof ;)  But on general level it handles the stuff a backend
> > > needs to do, just does not have most of the operations or capabilities
> > > available. OTOH having the backend defined means that if some of the
> > > capabilites would be added, there is a natural place to add it.
> > >   
> > 
> > But there's nothing you can control from Linux right?
> > 
> > > >   
> > > > > allows for customer integrations with backends that differ but are of no
> > > > > interest for the mainline.
> > > > >   
> > > > 
> > > > It would still be nice to have this usecase fully supported upstream 
> > > > (having a black box backend). 
> > > > 
> > > > 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.

- Nuno Sá

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@gmail.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á
>