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>
---
drivers/iio/adc/ad9467.c | 37 +++++++++++++++++++++++++------------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
index 60fc3361b2689a4c38287c613ef93fe00338e5fa..37b8f88da6681d44f3fbbb6c8c171ae7117b9090 100644
--- a/drivers/iio/adc/ad9467.c
+++ b/drivers/iio/adc/ad9467.c
@@ -1000,6 +1000,9 @@ static int ad9467_update_scan_mode(struct iio_dev *indio_dev,
unsigned int c;
int ret;
+ if (!st->back)
+ return -EOPNOTSUPP;
+
for (c = 0; c < st->info->num_channels; c++) {
if (test_bit(c, scan_mask))
ret = iio_backend_chan_enable(st->back, c);
@@ -1066,6 +1069,7 @@ static int ad9467_iio_backend_get(struct ad9467_state *st)
{
struct device *dev = &st->spi->dev;
struct device_node *__back;
+ unsigned int nr_nodes = 0;
st->back = devm_iio_backend_get(dev, NULL);
if (!IS_ERR(st->back))
@@ -1084,6 +1088,7 @@ static int ad9467_iio_backend_get(struct ad9467_state *st)
for_each_node_with_property(__back, "adi,adc-dev") {
struct device_node *__me;
+ nr_nodes++;
__me = of_parse_phandle(__back, "adi,adc-dev", 0);
if (!__me)
continue;
@@ -1100,6 +1105,10 @@ static int ad9467_iio_backend_get(struct ad9467_state *st)
return PTR_ERR_OR_ZERO(st->back);
}
+ st->back = NULL;
+ if (!nr_nodes)
+ return -ENOENT;
+
return -ENODEV;
}
@@ -1294,8 +1303,8 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
debugfs_create_file("in_voltage_test_mode_available", 0400, d, st,
&ad9467_test_mode_available_fops);
-
- iio_backend_debugfs_add(st->back, indio_dev);
+ if (st->back)
+ iio_backend_debugfs_add(st->back, indio_dev);
}
static int ad9467_probe(struct spi_device *spi)
@@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
indio_dev->channels = st->info->channels;
indio_dev->num_channels = st->info->num_channels;
+ /* Using a backend is optional */
ret = ad9467_iio_backend_get(st);
- if (ret)
+ if (ret && ret != -ENOENT)
return ret;
- ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
- if (ret)
- return ret;
+ if (!ret) {
+ ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
+ indio_dev);
+ if (ret)
+ return ret;
- ret = devm_iio_backend_enable(&spi->dev, st->back);
- if (ret)
- return ret;
+ ret = devm_iio_backend_enable(&spi->dev, st->back);
+ if (ret)
+ return ret;
- ret = ad9467_calibrate(st);
- if (ret)
- return ret;
+ ret = ad9467_calibrate(st);
+ if (ret)
+ return ret;
+ }
ret = devm_iio_device_register(&spi->dev, indio_dev);
if (ret)
--
2.47.3On Tue, 16 Dec 2025 11:40:06 +0000 Tomas Melin <tomas.melin@vaisala.com> 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> Hi Tomas, > static int ad9467_probe(struct spi_device *spi) > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi) > indio_dev->channels = st->info->channels; > indio_dev->num_channels = st->info->num_channels; > > + /* Using a backend is optional */ I'll largely defer to Nuno on the backend aspects but I would like a lot more than a statement that it is optional in this comment. At least something about where the data goes and what a real system that didn't provide a backend would look like etc. I can think of some setups where I'd be fine with this change and others where I'd push back harder. Jonathan
Hi, On 21/12/2025 22:00, Jonathan Cameron wrote: > On Tue, 16 Dec 2025 11:40:06 +0000 > Tomas Melin <tomas.melin@vaisala.com> 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> > Hi Tomas, > >> static int ad9467_probe(struct spi_device *spi) >> @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi) >> indio_dev->channels = st->info->channels; >> indio_dev->num_channels = st->info->num_channels; >> >> + /* Using a backend is optional */ > > I'll largely defer to Nuno on the backend aspects but I would like a > lot more than a statement that it is optional in this comment. > At least something about where the data goes and what a real system > that didn't provide a backend would look like etc. Having the backend as optional is about flexibility to incorporate these devices as fits best with the system. The current backend approach is pretty much dictated with how the ADI default backend is implemented. These devices are fully configurable via SPI interface so the backend doesn't necessarily need to be anything fancy or even configurable. So there is atleast two use cases that promote the optional iio-backend approach - simple backend that is not configurable, no need for a dedicated driver. The backend (FPGA) sits and waits for data and handles it when it arrives - custom backend not compatible with the adi backend features. For example different approach to calibration, or other model for data channels etc. Not having it optional would mean more or less vendor lock with analog devices backend which probably was not the idea when adding the iio-backend feature in the first place. Regarding the comment, perhaps something like /** * Backend provided features are optional. If a compatible backend is * not present all features might not be available. If the system * otherwise provides a path for the data, the device will still be * fully functional. **/ > > I can think of some setups where I'd be fine with this change and others > where I'd push back harder. Given the explanations above, I'd be happy to have some more feedback on this. Thanks, Tomas > > Jonathan >
On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote: > Hi, > > On 21/12/2025 22:00, Jonathan Cameron wrote: > > On Tue, 16 Dec 2025 11:40:06 +0000 > > Tomas Melin <tomas.melin@vaisala.com> 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> > > Hi Tomas, > > > > > static int ad9467_probe(struct spi_device *spi) > > > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi) > > > indio_dev->channels = st->info->channels; > > > indio_dev->num_channels = st->info->num_channels; > > > > > > + /* Using a backend is optional */ > > > > I'll largely defer to Nuno on the backend aspects but I would like a > > lot more than a statement that it is optional in this comment. > > At least something about where the data goes and what a real system > > that didn't provide a backend would look like etc. > > Having the backend as optional is about flexibility to incorporate these > devices as fits best with the system. The current backend approach is > pretty much dictated with how the ADI default backend is implemented. > These devices are fully configurable via SPI interface so the backend > doesn't necessarily need to be anything fancy or even configurable. > > So there is atleast two use cases that promote the optional iio-backend > approach > - simple backend that is not configurable, no need for a dedicated > driver. The backend (FPGA) sits and waits for data and handles it when > it arrives Agree on the above. Ideally we could have some dummy backend for the above but it is not really easy/maintainable to have it. > - custom backend not compatible with the adi backend features. For > example different approach to calibration, or other model for data > channels etc. I would argue the above would require a new driver with, perhaps, a new compatible on the frontend side for the needed modifications. Or we could introduce some kind of "detect backend vendor thing" so that the frontend driver can adapt at runtime (though this looks like a "fancier" way of having a new compatible). Ideally we could somehow "detect" backend capabilities but these kind of systems are so different and usecase specific that, at least for now, I don't see how that could be sanely done. - Nuno Sá >
On Mon, 05 Jan 2026 14:57:02 +0000 Nuno Sá <noname.nuno@gmail.com> wrote: > On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote: > > Hi, > > > > On 21/12/2025 22:00, Jonathan Cameron wrote: > > > On Tue, 16 Dec 2025 11:40:06 +0000 > > > Tomas Melin <tomas.melin@vaisala.com> 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> > > > Hi Tomas, > > > > > > > static int ad9467_probe(struct spi_device *spi) > > > > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi) > > > > indio_dev->channels = st->info->channels; > > > > indio_dev->num_channels = st->info->num_channels; > > > > > > > > + /* Using a backend is optional */ > > > > > > I'll largely defer to Nuno on the backend aspects but I would like a > > > lot more than a statement that it is optional in this comment. > > > At least something about where the data goes and what a real system > > > that didn't provide a backend would look like etc. > > > > Having the backend as optional is about flexibility to incorporate these > > devices as fits best with the system. The current backend approach is > > pretty much dictated with how the ADI default backend is implemented. > > These devices are fully configurable via SPI interface so the backend > > doesn't necessarily need to be anything fancy or even configurable. > > > > So there is atleast two use cases that promote the optional iio-backend > > approach > > - simple backend that is not configurable, no need for a dedicated > > driver. The backend (FPGA) sits and waits for data and handles it when > > it arrives > > Agree on the above. Ideally we could have some dummy backend for the above but > it is not really easy/maintainable to have it. When we say the backend needs no driver, where does the data end up? Is the idea that it goes into some processing pipeline and sent to some external path that we have no visibility of? i.e. We configure the data capture in Linux but never see the data? > > > - custom backend not compatible with the adi backend features. For > > example different approach to calibration, or other model for data > > channels etc. > > I would argue the above would require a new driver with, perhaps, a new compatible > on the frontend side for the needed modifications. Or we could introduce some kind > of "detect backend vendor thing" so that the frontend driver can adapt at runtime > (though this looks like a "fancier" way of having a new compatible). > > Ideally we could somehow "detect" backend capabilities but these kind of systems are > so different and usecase specific that, at least for now, I don't see how that could be > sanely done. Agreed. If we need to extend things to deal with other styles of FPGA IP or different feature sets, that is the way to go. That would require some public implementation that uses the interface Jonathan > > - Nuno Sá > > >
On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote: > On Mon, 05 Jan 2026 14:57:02 +0000 > Nuno Sá <noname.nuno@gmail.com> wrote: > > > On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote: > > > Hi, > > > > > > On 21/12/2025 22:00, Jonathan Cameron wrote: > > > > On Tue, 16 Dec 2025 11:40:06 +0000 > > > > Tomas Melin <tomas.melin@vaisala.com> 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> > > > > Hi Tomas, > > > > > > > > > static int ad9467_probe(struct spi_device *spi) > > > > > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi) > > > > > indio_dev->channels = st->info->channels; > > > > > indio_dev->num_channels = st->info->num_channels; > > > > > > > > > > + /* Using a backend is optional */ > > > > > > > > I'll largely defer to Nuno on the backend aspects but I would like a > > > > lot more than a statement that it is optional in this comment. > > > > At least something about where the data goes and what a real system > > > > that didn't provide a backend would look like etc. > > > > > > Having the backend as optional is about flexibility to incorporate these > > > devices as fits best with the system. The current backend approach is > > > pretty much dictated with how the ADI default backend is implemented. > > > These devices are fully configurable via SPI interface so the backend > > > doesn't necessarily need to be anything fancy or even configurable. > > > > > > So there is atleast two use cases that promote the optional iio-backend > > > approach > > > - simple backend that is not configurable, no need for a dedicated > > > driver. The backend (FPGA) sits and waits for data and handles it when > > > it arrives > > > > Agree on the above. Ideally we could have some dummy backend for the above but > > it is not really easy/maintainable to have it. > > When we say the backend needs no driver, where does the data end up? > Is the idea that it goes into some processing pipeline and sent to > some external path that we have no visibility of? i.e. We configure the > data capture in Linux but never see the data? Yes, that's also my assumption about Tomas's usecase. - Nuno Sá
Hi, On 12/01/2026 15:21, Nuno Sá wrote: > On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote: >> On Mon, 05 Jan 2026 14:57:02 +0000 >> Nuno Sá <noname.nuno@gmail.com> wrote: >> >>> On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote: >>>> Hi, >>>> >>>> On 21/12/2025 22:00, Jonathan Cameron wrote: >>>>> On Tue, 16 Dec 2025 11:40:06 +0000 >>>>> Tomas Melin <tomas.melin@vaisala.com> 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> >>>>> Hi Tomas, >>>>> >>>>>> static int ad9467_probe(struct spi_device *spi) >>>>>> @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi) >>>>>> indio_dev->channels = st->info->channels; >>>>>> indio_dev->num_channels = st->info->num_channels; >>>>>> >>>>>> + /* Using a backend is optional */ >>>>> >>>>> I'll largely defer to Nuno on the backend aspects but I would like a >>>>> lot more than a statement that it is optional in this comment. >>>>> At least something about where the data goes and what a real system >>>>> that didn't provide a backend would look like etc. >>>> >>>> Having the backend as optional is about flexibility to incorporate these >>>> devices as fits best with the system. The current backend approach is >>>> pretty much dictated with how the ADI default backend is implemented. >>>> These devices are fully configurable via SPI interface so the backend >>>> doesn't necessarily need to be anything fancy or even configurable. >>>> >>>> So there is atleast two use cases that promote the optional iio-backend >>>> approach >>>> - simple backend that is not configurable, no need for a dedicated >>>> driver. The backend (FPGA) sits and waits for data and handles it when >>>> it arrives >>> >>> Agree on the above. Ideally we could have some dummy backend for the above but >>> it is not really easy/maintainable to have it. >> >> When we say the backend needs no driver, where does the data end up? >> Is the idea that it goes into some processing pipeline and sent to >> some external path that we have no visibility of? i.e. We configure the >> data capture in Linux but never see the data? > > Yes, that's also my assumption about Tomas's usecase. The data becomes available to user space but there is currently no immediate need or natural place to create a separate instance to function as a backend device. But that being said, I'm leaning towards thinking that perhaps a minimalistic backend should always be registered after all. That would keep the idea of the backend always existing intact. But since the backend can be missing a lot of the features defined for the current ADI backend, capability handling would need to be added to the backend framework to make it functional. Looking into how this could be achieved with reasonable impact, I have tried to identify capabilities that we could add for starters, and then have the frontend behave differently depending on what features are present. Something like this (added to backend_info), .caps = IIO_BACKEND_CAP_TEST_PATTERNS | --> backend patterns are avail. IIO_BACKEND_CAP_BUFFERING | --> backend has buffering cap. IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration If you think this seems reasonable, I can implement something like this and post a new version for comments. Thanks, Tomas > > - Nuno Sá
On Tue, 2026-01-13 at 09:47 +0200, Tomas Melin wrote: > Hi, > > On 12/01/2026 15:21, Nuno Sá wrote: > > On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote: > > > On Mon, 05 Jan 2026 14:57:02 +0000 > > > Nuno Sá <noname.nuno@gmail.com> wrote: > > > > > > > On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote: > > > > > Hi, > > > > > > > > > > On 21/12/2025 22:00, Jonathan Cameron wrote: > > > > > > On Tue, 16 Dec 2025 11:40:06 +0000 > > > > > > Tomas Melin <tomas.melin@vaisala.com> 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> > > > > > > Hi Tomas, > > > > > > > > > > > > > static int ad9467_probe(struct spi_device *spi) > > > > > > > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi) > > > > > > > indio_dev->channels = st->info->channels; > > > > > > > indio_dev->num_channels = st->info->num_channels; > > > > > > > > > > > > > > + /* Using a backend is optional */ > > > > > > > > > > > > I'll largely defer to Nuno on the backend aspects but I would like a > > > > > > lot more than a statement that it is optional in this comment. > > > > > > At least something about where the data goes and what a real system > > > > > > that didn't provide a backend would look like etc. > > > > > > > > > > Having the backend as optional is about flexibility to incorporate these > > > > > devices as fits best with the system. The current backend approach is > > > > > pretty much dictated with how the ADI default backend is implemented. > > > > > These devices are fully configurable via SPI interface so the backend > > > > > doesn't necessarily need to be anything fancy or even configurable. > > > > > > > > > > So there is atleast two use cases that promote the optional iio-backend > > > > > approach > > > > > - simple backend that is not configurable, no need for a dedicated > > > > > driver. The backend (FPGA) sits and waits for data and handles it when > > > > > it arrives > > > > > > > > Agree on the above. Ideally we could have some dummy backend for the above but > > > > it is not really easy/maintainable to have it. > > > > > > When we say the backend needs no driver, where does the data end up? > > > Is the idea that it goes into some processing pipeline and sent to > > > some external path that we have no visibility of? i.e. We configure the > > > data capture in Linux but never see the data? > > > > Yes, that's also my assumption about Tomas's usecase. > > The data becomes available to user space but there is currently no > immediate need or natural place to create a separate instance to > function as a backend device. So do you have some completely different data path bypassing IIO (just curious)? > > But that being said, I'm leaning towards thinking that perhaps a > minimalistic backend should always be registered after all. That would > keep the idea of the backend always existing intact. > But since the backend can be missing a lot of the features defined for > the current ADI backend, capability handling would need to be added to > the backend framework to make it functional. > > Looking into how this could be achieved with reasonable impact, I have > tried to identify capabilities that we could add for starters, and then > have the frontend behave differently depending on what features are present. > > Something like this (added to backend_info), > .caps = IIO_BACKEND_CAP_TEST_PATTERNS | --> backend patterns are avail. > IIO_BACKEND_CAP_BUFFERING | --> backend has buffering cap. > IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration > Looks reasonable but I'm still a bit afraid to open this can of worms. But as Jonathan pointed out multiple times on the backend code, this is mostly inkernel interfaces so it is easier to deal with bad choices :). We would still need to "combine" these capabilities feature with a dummy backend that would dummy implement the more common/expected like (chan)enable/disable and so on. We can then decide on a usecase by usecase basis on what should be a capability or what should be dummy implemented. Bottom line, I'm leaning on "I'm ok with the above" since I expect usecases like this to be fairly rare (famous last words :)). And It would be nice to have more feedback on this one. - Nuno Sá
Hi, On 13/01/2026 12:52, Nuno Sá wrote: > On Tue, 2026-01-13 at 09:47 +0200, Tomas Melin wrote: >> Hi, >> >> On 12/01/2026 15:21, Nuno Sá wrote: >>> On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote: >>>> On Mon, 05 Jan 2026 14:57:02 +0000 >>>> Nuno Sá <noname.nuno@gmail.com> wrote: >>>> >>>>> On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote: >>>> >>>> When we say the backend needs no driver, where does the data end up? >>>> Is the idea that it goes into some processing pipeline and sent to >>>> some external path that we have no visibility of? i.e. We configure the >>>> data capture in Linux but never see the data? >>> >>> Yes, that's also my assumption about Tomas's usecase. >> >> The data becomes available to user space but there is currently no >> immediate need or natural place to create a separate instance to >> function as a backend device. > > So do you have some completely different data path bypassing IIO (just curious)? Yes, IP handles data reception and data transfer outside of iio context. > >> >> But that being said, I'm leaning towards thinking that perhaps a >> minimalistic backend should always be registered after all. That would >> keep the idea of the backend always existing intact. >> But since the backend can be missing a lot of the features defined for >> the current ADI backend, capability handling would need to be added to >> the backend framework to make it functional. >> >> Looking into how this could be achieved with reasonable impact, I have >> tried to identify capabilities that we could add for starters, and then >> have the frontend behave differently depending on what features are present. >> >> Something like this (added to backend_info), >> .caps = IIO_BACKEND_CAP_TEST_PATTERNS | --> backend patterns are avail. >> IIO_BACKEND_CAP_BUFFERING | --> backend has buffering cap. >> IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration >> > > Looks reasonable but I'm still a bit afraid to open this can of worms. But as Jonathan > pointed out multiple times on the backend code, this is mostly inkernel interfaces so > it is easier to deal with bad choices :). I understand this concern, but would anticipate that there are only a limited number of capabilties that need to be handled, so it should stay fairly managable. > > > We would still need to "combine" these capabilities feature with a dummy backend that > would dummy implement the more common/expected like (chan)enable/disable and so on. I think the dummy backend is probably not gonna be needed as the current axi backend can advertise the available set of capabilities. The frontends are then free to make use of the capability bits as needed. In my use case, I need to implement a limited backend that does not claim any capabilities but only provides a minimum set of functionality. Thanks, Tomas > > We can then decide on a usecase by usecase basis on what should be a capability or what > should be dummy implemented. > > Bottom line, I'm leaning on "I'm ok with the above" since I expect usecases like this to > be fairly rare (famous last words :)). And It would be nice to have more feedback > on this one. > > - Nuno Sá >
On Tue, 2026-01-13 at 13:49 +0200, Tomas Melin wrote: > Hi, > > On 13/01/2026 12:52, Nuno Sá wrote: > > On Tue, 2026-01-13 at 09:47 +0200, Tomas Melin wrote: > > > Hi, > > > > > > On 12/01/2026 15:21, Nuno Sá wrote: > > > > On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote: > > > > > On Mon, 05 Jan 2026 14:57:02 +0000 > > > > > Nuno Sá <noname.nuno@gmail.com> wrote: > > > > > > > > > > > On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote: > > > > > > > > > > > When we say the backend needs no driver, where does the data end up? > > > > > Is the idea that it goes into some processing pipeline and sent to > > > > > some external path that we have no visibility of? i.e. We configure the > > > > > data capture in Linux but never see the data? > > > > > > > > Yes, that's also my assumption about Tomas's usecase. > > > > > > The data becomes available to user space but there is currently no > > > immediate need or natural place to create a separate instance to > > > function as a backend device. > > > > So do you have some completely different data path bypassing IIO (just curious)? > > Yes, IP handles data reception and data transfer outside of iio context. > > > > > > > > > But that being said, I'm leaning towards thinking that perhaps a > > > minimalistic backend should always be registered after all. That would > > > keep the idea of the backend always existing intact. > > > But since the backend can be missing a lot of the features defined for > > > the current ADI backend, capability handling would need to be added to > > > the backend framework to make it functional. > > > > > > Looking into how this could be achieved with reasonable impact, I have > > > tried to identify capabilities that we could add for starters, and then > > > have the frontend behave differently depending on what features are present. > > > > > > Something like this (added to backend_info), > > > .caps = IIO_BACKEND_CAP_TEST_PATTERNS | --> backend patterns are avail. > > > IIO_BACKEND_CAP_BUFFERING | --> backend has buffering cap. > > > IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration > > > > > > > Looks reasonable but I'm still a bit afraid to open this can of worms. But as Jonathan > > pointed out multiple times on the backend code, this is mostly inkernel interfaces so > > it is easier to deal with bad choices :). > > I understand this concern, but would anticipate that there are only a > limited number of capabilties that need to be handled, so it should stay > fairly managable. > > > > > > > We would still need to "combine" these capabilities feature with a dummy backend that > > would dummy implement the more common/expected like (chan)enable/disable and so on. > > I think the dummy backend is probably not gonna be needed as the current > axi backend can advertise the available set of capabilities. The > frontends are then free to make use of the capability bits as needed. > In my use case, I need to implement a limited backend that does not > claim any capabilities but only provides a minimum set of functionality. > Ok, looking at the driver indeed it seems we would not need much advertised. Let's see how something like the above would look like and discuss on top of that. - Nuno Sá
On Tue, 13 Jan 2026 09:47:46 +0200 Tomas Melin <tomas.melin@vaisala.com> wrote: > Hi, > > On 12/01/2026 15:21, Nuno Sá wrote: > > On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote: > >> On Mon, 05 Jan 2026 14:57:02 +0000 > >> Nuno Sá <noname.nuno@gmail.com> wrote: > >> > >>> On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote: > >>>> Hi, > >>>> > >>>> On 21/12/2025 22:00, Jonathan Cameron wrote: > >>>>> On Tue, 16 Dec 2025 11:40:06 +0000 > >>>>> Tomas Melin <tomas.melin@vaisala.com> 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> > >>>>> Hi Tomas, > >>>>> > >>>>>> static int ad9467_probe(struct spi_device *spi) > >>>>>> @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi) > >>>>>> indio_dev->channels = st->info->channels; > >>>>>> indio_dev->num_channels = st->info->num_channels; > >>>>>> > >>>>>> + /* Using a backend is optional */ > >>>>> > >>>>> I'll largely defer to Nuno on the backend aspects but I would like a > >>>>> lot more than a statement that it is optional in this comment. > >>>>> At least something about where the data goes and what a real system > >>>>> that didn't provide a backend would look like etc. > >>>> > >>>> Having the backend as optional is about flexibility to incorporate these > >>>> devices as fits best with the system. The current backend approach is > >>>> pretty much dictated with how the ADI default backend is implemented. > >>>> These devices are fully configurable via SPI interface so the backend > >>>> doesn't necessarily need to be anything fancy or even configurable. > >>>> > >>>> So there is atleast two use cases that promote the optional iio-backend > >>>> approach > >>>> - simple backend that is not configurable, no need for a dedicated > >>>> driver. The backend (FPGA) sits and waits for data and handles it when > >>>> it arrives > >>> > >>> Agree on the above. Ideally we could have some dummy backend for the above but > >>> it is not really easy/maintainable to have it. > >> > >> When we say the backend needs no driver, where does the data end up? > >> Is the idea that it goes into some processing pipeline and sent to > >> some external path that we have no visibility of? i.e. We configure the > >> data capture in Linux but never see the data? > > > > Yes, that's also my assumption about Tomas's usecase. > > The data becomes available to user space but there is currently no > immediate need or natural place to create a separate instance to > function as a backend device. > > But that being said, I'm leaning towards thinking that perhaps a > minimalistic backend should always be registered after all. That would > keep the idea of the backend always existing intact. > But since the backend can be missing a lot of the features defined for > the current ADI backend, capability handling would need to be added to > the backend framework to make it functional. > > Looking into how this could be achieved with reasonable impact, I have > tried to identify capabilities that we could add for starters, and then > have the frontend behave differently depending on what features are present. > > Something like this (added to backend_info), > .caps = IIO_BACKEND_CAP_TEST_PATTERNS | --> backend patterns are avail. > IIO_BACKEND_CAP_BUFFERING | --> backend has buffering cap. > IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration > > If you think this seems reasonable, I can implement something like this > and post a new version for comments. > Sounds good to me, but I defer to Nuno for backend stuff! Thanks, Jonathan > Thanks, > Tomas > > > > > > > - Nuno Sá > > >
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> > --- > drivers/iio/adc/ad9467.c | 37 +++++++++++++++++++++++++------------ > 1 file changed, 25 insertions(+), 12 deletions(-) > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > index 60fc3361b2689a4c38287c613ef93fe00338e5fa..37b8f88da6681d44f3fbbb6c8c171ae7117b9090 100644 > --- a/drivers/iio/adc/ad9467.c > +++ b/drivers/iio/adc/ad9467.c > @@ -1000,6 +1000,9 @@ static int ad9467_update_scan_mode(struct iio_dev *indio_dev, > unsigned int c; > int ret; > > + if (!st->back) > + return -EOPNOTSUPP; > + Let's not add the buffering interface if we can't control it. Having it just to return error does not make sense to me. This means yet another info: https://elixir.bootlin.com/linux/v6.18.1/source/drivers/iio/adc/ad9467.c#L916 Also the channel definition should not have the scan index. But, given that the IIO device won't have any buffer I think there's no way to reach ad9467_update_scan_mode() (unless I'm missing something). Still, while I understand that updating the channels to not include the scan_index is very cumbersome, having a new iio_info with no .update_scan_mode() is trivial and make things more clear and explicit. - Nuno Sá
On 18/12/2025 15:49, 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> >> --- >> drivers/iio/adc/ad9467.c | 37 +++++++++++++++++++++++++------------ >> 1 file changed, 25 insertions(+), 12 deletions(-) >> >> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c >> index 60fc3361b2689a4c38287c613ef93fe00338e5fa..37b8f88da6681d44f3fbbb6c8c171ae7117b9090 100644 >> --- a/drivers/iio/adc/ad9467.c >> +++ b/drivers/iio/adc/ad9467.c >> @@ -1000,6 +1000,9 @@ static int ad9467_update_scan_mode(struct iio_dev *indio_dev, >> unsigned int c; >> int ret; >> >> + if (!st->back) >> + return -EOPNOTSUPP; >> + > > Let's not add the buffering interface if we can't control it. > Having it just to return error does not make sense to me. This means yet another info: > > https://elixir.bootlin.com/linux/v6.18.1/source/drivers/iio/adc/ad9467.c#L916 > I agree, not having the scan_mode at all would be more clean. But adding those different iio_info structs comes across as a bit messy. Would it make sense to create that iio_info dynamically in the probe and fill out the callbacks that are supported for the configuration we encounter? I could try out something like that and see how it would look like in practice. Thanks, Tomas > Also the channel definition should not have the scan index. But, given that the IIO device > won't have any buffer I think there's no way to reach ad9467_update_scan_mode() (unless I'm > missing something). > > Still, while I understand that updating the channels to not include the scan_index is very > cumbersome, having a new iio_info with no .update_scan_mode() is trivial and make things > more clear and explicit. > > - Nuno Sá >
On Fri, 2025-12-19 at 13:16 +0200, Tomas Melin wrote: > > On 18/12/2025 15:49, 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> > > > --- > > > drivers/iio/adc/ad9467.c | 37 +++++++++++++++++++++++++------------ > > > 1 file changed, 25 insertions(+), 12 deletions(-) > > > > > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > > > index 60fc3361b2689a4c38287c613ef93fe00338e5fa..37b8f88da6681d44f3fbbb6c8c171ae7117b9090 > > > 100644 > > > --- a/drivers/iio/adc/ad9467.c > > > +++ b/drivers/iio/adc/ad9467.c > > > @@ -1000,6 +1000,9 @@ static int ad9467_update_scan_mode(struct iio_dev *indio_dev, > > > unsigned int c; > > > int ret; > > > > > > + if (!st->back) > > > + return -EOPNOTSUPP; > > > + > > > > Let's not add the buffering interface if we can't control it. > > Having it just to return error does not make sense to me. This means yet another info: > > > > https://elixir.bootlin.com/linux/v6.18.1/source/drivers/iio/adc/ad9467.c#L916 > > > > I agree, not having the scan_mode at all would be more clean. > But adding those different iio_info structs comes across as a bit messy. > Would it make sense to create that iio_info dynamically in the probe and > fill out the callbacks that are supported for the configuration we > encounter? I could try out something like that and see how it would look > like in practice. > Hmm yeah, it's not just one more iio_info we need but 2. But maybe let's keep it simple and remove the check in ad9467_update_scan_mode(). I mean, if I'm not missing nothing, if there's no buffer, there's no real way for userspace to reach that code path. - Nuno Sá >
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 :)). - Nuno Sá
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. 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? Thanks, Tomas > > - Nuno Sá >
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... > 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. Other question that comes to mind (I guess I was not that clear)... Do you have a real usecase with your own custom backend IP or is this just theoretical? - Nuno Sá
[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. > >> 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. 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. > > Other question that comes to mind (I guess I was not that clear)... Do you have a real > usecase with your own custom backend IP or is this just theoretical? This dependency on the adi hdl has been causing me problems over the years for a number of adi devices, and the iio-backend has been a step in the right direction. I hope we can take this further in direction that allows use cases that were not expected from the beginning but are still valid. Thanks, Tomas > > - Nuno Sá
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á
Hi, On 18/12/2025 15:41, Nuno Sá wrote: > 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: > > 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. Good that you still see the optional backend as feasible. I will tune the implementation in next version according to discussion in our other thread and other possible feeback that comes up. I'm confident we can find a solution that will work out nicely. Thanks, Tomas > > - Nuno Sá >
On 12/16/25 9:39 AM, 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. If you have your own backend, why would it not use the IIO backend framework? I can understand if this custom backend sends the data somewhere else besides an IIO buffer and we don't want to create the buffer for the IIO device. But I would still think that there needs to be some sort of communication between the IIO device and the backend. Maybe you could explain more how this custom backend is intended to work? > 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? > > Thanks, > Tomas > > >> >> - Nuno Sá >> >
Hi, On 16/12/2025 23:27, David Lechner wrote: > On 12/16/25 9:39 AM, 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. > > If you have your own backend, why would it not use the IIO backend > framework? > > I can understand if this custom backend sends the data somewhere else > besides an IIO buffer and we don't want to create the buffer for the IIO > device. But I would still think that there needs to be some sort of > communication between the IIO device and the backend. True, there needs to some kind of backend, but they don't all have iio backends or other kernel drivers. Data will flow when the device starts sending without much further need to configure. Adding a backend driver in these cases could have some benefits, but often it would just be an unneeded complication. And even if there were a custom iio-backend available, it would not be compatible with the current assumptions about ADI backend wrt calibration, test mode enabling and iio buffering. So having a strict dependency on an iio-backend does not really work in a generic use case. > > Maybe you could explain more how this custom backend is intended to work? I hope the explanation above helps. There is real use case behind, this is not some imaginary nice to have feature. Before the introduction of the iio backend, the driver was even more dependent on the backend. At that point, needed to carry some out of tree patches to remove the dependency and make it a standalone iio driver. Thankfully with the introduction of the iio-backend, this is now more loosely coupled and I see opportunity for making this standalone mode possible also in mainline. Thanks, Tomas > >> 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? >> >> Thanks, >> Tomas >> >> >>> >>> - Nuno Sá >>> >> >
© 2016 - 2026 Red Hat, Inc.