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

["Nuno Sá" <noname.nuno@gmail.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á