Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

["Nuno Sá" <noname.nuno@gmail.com>]

On Wed, 2025-12-17 at 13:44 +0200, Tomas Melin wrote:
> [resend, I think there was some problem with my first reply]
> 
> Hi,
> 
> On 17/12/2025 11:26, Nuno Sá wrote:
> > On Tue, 2025-12-16 at 15:39 +0000, Tomas Melin wrote:
> > > Hi,
> > > 
> > > On 16/12/2025 14:56, Nuno Sá wrote:
> > > > On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
> > > > > Not all users can or want to use the device with an iio-backend.
> > > > > For these users, let the driver work in standalone mode, not coupled
> > > > > to the backend or the services it provides.
> > > > > 
> > > > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> > > > > ---
> > > > 
> > > > Which users? The only usecases (for all the supported devices) we have require
> > > > the FPGA backend. So do you have a specific usecase for a specific device? If so, I would
> > > > prefer an explicit boolean in the chip_info struture for the device(s) we know this
> > > > can happen (unless you have a usecase for all :)).
> > > 
> > > This is generically for all the devices supported by the ad9467, not
> > > only a specific device. So it's about how this is used as part of the
> > > design.
> > > 
> > > This is aimed at users that do not use the ADI HDL reference backend
> > > with these devices, but instead have custom backends suited for their
> > > own needs.
> > 
> > Hmm, ideally I would then like to see the backend driver upstreamed...
> 
> First of all, as I responded in another thread, there is certainly real
> use case behind this, I would not be suggesting it otherwise.
> 
> Driver for custom backend would not be of any interest for mainline
> kernel as the IP would not be publicly available. So nobody could really
> use such a driver, nor would it be accepted. The default ADI backend is
>  a different story, as it is available and documented.

I see.

> 
> > 
> > > In that case, we need to be able to skip the backend registration and
> > > register device as a standalone iio device.
> > > 
> > > Hopefully this made the use case clearer?
> > > 
> > 
> > I mean, I don't love this and I'm not really sure I'm ok with it. These are fairly
> > high speed devices which often do require an FPGA IP to handle the data flow. Now
> > we can ignore the backend device (which is an essential piece) being it
> > expected or not.
> > 
> > Or maybe we can just do something like regulators and get a dummy backend or just add
> > some fixed kind of backend. Bottom line is, it still seems the backend device is a core
> > piece in your design and we're just hacking around the driver in way that conceptually
> > doesn't make sense to me.
> 
> I considered the idea of dummy backend, but in the end it doesn't make
> much sense to me.
> These ADCs can work perfectly fine with a minimalistic custom backend
> that does exactly what the design needs, without the need for basically
> any configuration. So the ADCs rely on some sort of backend, ofcourse,
> but they are in the end standalone devices that can be integrated in
> many ways, the adi backend being only one such option.

There we have it. It relies on some external HW so conceptually the dummy would
make sense me. In the same way a device cannot work without power supply and hence
we get the dummy regulator. But...

> 
> Another problem with a dummy backend is that for example calibration
> cannot really work. It expects certain features from the backend to be
> available, etc. Similarly would a custom backend connected need to
> implemented exactly same test features as the backend now assumes.
> 

The above is indeed cumbersome. I guess dummy is not what we would need but something
like a fixed-backend that would implement all the ops in a dummy way. But that does not
make much sense and doesn't really scale.

I think my main complain is also that then we should add a devm_backend_get_optional() to make
the intent clear but unfortunately this driver is not the best candidate for that.

Anyways, I still don't love the idea of just ignoring it (given that some HW is indeed present)
but yeah. Not going to nack it either.

- Nuno Sá