Message-ID: <fc350d2605ca6d95facec1a67858cb0ac22db917.camel@gmail.com>
Date: Tue, 03 Feb 2026 10:01:03 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Tomas Melin <tomas.melin@...sala.com>, David Lechner
 <dlechner@...libre.com>,  Michael Hennerich <Michael.Hennerich@...log.com>,
 Nuno Sa <nuno.sa@...log.com>, Lars-Peter Clausen <lars@...afoo.de>, 
 Jonathan Cameron	 <jic23@...nel.org>, Andy Shevchenko <andy@...nel.org>,
 Olivier Moysan	 <olivier.moysan@...s.st.com>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/4] iio: industrialio-backend: support backend
 capabilities

On Mon, 2026-02-02 at 15:04 +0200, Tomas Melin wrote:
> Hi,
> 
> On 02/02/2026 14:40, Nuno Sá wrote:
> > 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.
> 
> Yes, this is debatable. It's not necessarily always on, but should not
> be enabled/touched by the frontend during probe.
> But anyways, having a capability that says if the enable/disable feature
> is available, is in any case useful and what I was planning on
> leveraging in my use case.
> Fundamentally, with the capabilites as now proposed, it is possible to
> select what features of the ad9467 are available, in addition to the
> basic requirements.

Yeah but this is just tweaking for your special case. Like you said, if we ever have
something like "but should not be enabled/touched by the frontend during probe." then what David
suggests in his reply makes more sense to me and clearly fits the usecase. That's not what we have
here. Here we have a fixed, non (linux) managed hardware and we do have a pattern in other
subsystems for HW like this. That is why my preferred approach would be a fixed-backend kind of
thing (naturally to be discussed with DT maintainers likely).
> 
> The ALWAYS_ON capability could be inverted, like CAP_HAS_ENABLE_DISABLE,
> but to me, the ALWAYS_ON naming still seems the better option.
> > 

But ok, I don't feel strong enough to be pushing for the above even though (and for the record :))
it's not my preferred approach. If every one else is fine with it, I won't object either.

- Nuno Sá

Powered by blists - more mailing lists