Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

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

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.

- Nuno Sá