Add capability checks for operation with backends that do not support
full set of features, but are otherwise compatible with the device.
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
drivers/iio/adc/ad9467.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..349779a049ad68b4c9f72abfc40154b4a3f2e095 100644
--- a/drivers/iio/adc/ad9467.c
+++ b/drivers/iio/adc/ad9467.c
@@ -645,6 +645,9 @@ static int ad9467_backend_testmode_on(struct ad9467_state *st,
};
int ret;
+ if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
+ return 0;
+
ret = iio_backend_data_format_set(st->back, chan, &data);
if (ret)
return ret;
@@ -665,6 +668,9 @@ static int ad9467_backend_testmode_off(struct ad9467_state *st,
};
int ret;
+ if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
+ return 0;
+
ret = iio_backend_chan_disable(st->back, chan);
if (ret)
return ret;
@@ -807,6 +813,9 @@ static int ad9467_calibrate(struct ad9467_state *st)
bool invert = false, stat;
int ret;
+ if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
+ return 0;
+
/* all points invalid */
bitmap_fill(st->calib_map, st->calib_map_size);
@@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
return ret;
ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
- if (ret)
+ if (ret && ret != -EOPNOTSUPP)
return ret;
ret = devm_iio_backend_enable(&spi->dev, st->back);
--
2.47.3On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote: > Add capability checks for operation with backends that do not support > full set of features, but are otherwise compatible with the device. > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com> > --- Another thing is that we also need to care about ad9467_debugfs_init(). No point in adding that interface if we cannot do (or get) anything with it. I guess we can still have the device specific test modes (without going to the backend) but "calibration_table_dump" does not make sense to add if IIO_BACKEND_CAP_CALIBRATION is off. With a dummy backend, iio_backend_debugfs_add() should already be a no-op. - Nuno Sá > drivers/iio/adc/ad9467.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..349779a049ad68b4c9f72abfc40154b4a3f2e095 100644 > --- a/drivers/iio/adc/ad9467.c > +++ b/drivers/iio/adc/ad9467.c > @@ -645,6 +645,9 @@ static int ad9467_backend_testmode_on(struct ad9467_state *st, > }; > int ret; > > + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) > + return 0; > + > ret = iio_backend_data_format_set(st->back, chan, &data); > if (ret) > return ret; > @@ -665,6 +668,9 @@ static int ad9467_backend_testmode_off(struct ad9467_state *st, > }; > int ret; > > + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) > + return 0; > + > ret = iio_backend_chan_disable(st->back, chan); > if (ret) > return ret; > @@ -807,6 +813,9 @@ static int ad9467_calibrate(struct ad9467_state *st) > bool invert = false, stat; > int ret; > > + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) > + return 0; > + > /* all points invalid */ > bitmap_fill(st->calib_map, st->calib_map_size); > > @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi) > return ret; > > ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev); > - if (ret) > + if (ret && ret != -EOPNOTSUPP) > return ret; > > ret = devm_iio_backend_enable(&spi->dev, st->back);
On Wed, 14 Jan 2026 10:45:53 +0000 Tomas Melin <tomas.melin@vaisala.com> wrote: > Add capability checks for operation with backends that do not support > full set of features, but are otherwise compatible with the device. > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com> Hi Tomas, A few comments inline around when we should or should not return errors. > --- > drivers/iio/adc/ad9467.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..349779a049ad68b4c9f72abfc40154b4a3f2e095 100644 > --- a/drivers/iio/adc/ad9467.c > +++ b/drivers/iio/adc/ad9467.c > @@ -645,6 +645,9 @@ static int ad9467_backend_testmode_on(struct ad9467_state *st, > }; > int ret; > > + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) > + return 0; If it isn't supported then isn't any attempt to turn test_mode on an error? I would return errors from all these calls and only decide it doesn't matter right at the top of the call stack. In this particular case that's either calibration mode stuff (covered by check below) or ad9467_chan_test_mod_write() I'd just add a top level check there on ability to do calibration. Alternative would be to not register the debugfs at all. Challenge is that is a small ABI break. Do we care? If we had been doing this from the start we would have just hidden the pointless interface. (Key is we can change userspace interfaces, as long no one notices!) > + > ret = iio_backend_data_format_set(st->back, chan, &data); > if (ret) > return ret; > @@ -665,6 +668,9 @@ static int ad9467_backend_testmode_off(struct ad9467_state *st, }; > int ret; > > + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) > + return 0; > + > ret = iio_backend_chan_disable(st->back, chan); > if (ret) > return ret; > @@ -807,6 +813,9 @@ static int ad9467_calibrate(struct ad9467_state *st) > bool invert = false, stat; > int ret; > > + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) > + return 0; So this the idea of a stub calibration bothers me a little, but I think it's more acceptable to do it for this top level call. So keep this one, but all the others look to me like they should be returning errors. > + > /* all points invalid */ > bitmap_fill(st->calib_map, st->calib_map_size); > > @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi) > return ret; > > ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev); > - if (ret) > + if (ret && ret != -EOPNOTSUPP) I don't see any modification of devm_iio_backend_request_buffer() in this set so why why is it now acceptable to return not supported? Given the capabilities stuff added, should this not be another capability we check before trying to request the buffer? > return ret; > > ret = devm_iio_backend_enable(&spi->dev, st->back); >
Hi, On 14/01/2026 14:45, Jonathan Cameron wrote: > On Wed, 14 Jan 2026 10:45:53 +0000 > Tomas Melin <tomas.melin@vaisala.com> wrote: > >> Add capability checks for operation with backends that do not support >> full set of features, but are otherwise compatible with the device. >> >> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com> > Hi Tomas, > > A few comments inline around when we should or should not return errors. > >> --- >> drivers/iio/adc/ad9467.c | 11 ++++++++++- >> 1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c >> index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..349779a049ad68b4c9f72abfc40154b4a3f2e095 100644 >> --- a/drivers/iio/adc/ad9467.c >> +++ b/drivers/iio/adc/ad9467.c >> @@ -645,6 +645,9 @@ static int ad9467_backend_testmode_on(struct ad9467_state *st, >> }; >> int ret; >> >> + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) >> + return 0; > > If it isn't supported then isn't any attempt to turn test_mode on an error? > I would return errors from all these calls and only decide it doesn't > matter right at the top of the call stack. I was considering this option too, I will change accordingly. > > In this particular case that's either calibration mode stuff (covered by check > below) or ad9467_chan_test_mod_write() I'd just add a top level check there > on ability to do calibration. Alternative would be to not register the debugfs > at all. Challenge is that is a small ABI break. Do we care? If we had > been doing this from the start we would have just hidden the pointless > interface. > (Key is we can change userspace interfaces, as long no one notices!) The testmodes from device side should still at least be there, only a few of the modes currently have a backend mode, too. > >> + >> ret = iio_backend_data_format_set(st->back, chan, &data); >> if (ret) >> return ret; >> @@ -665,6 +668,9 @@ static int ad9467_backend_testmode_off(struct ad9467_state *st, > }; >> int ret; >> >> + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) >> + return 0; >> + >> ret = iio_backend_chan_disable(st->back, chan); >> if (ret) >> return ret; >> @@ -807,6 +813,9 @@ static int ad9467_calibrate(struct ad9467_state *st) >> bool invert = false, stat; >> int ret; >> >> + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) >> + return 0; > > So this the idea of a stub calibration bothers me a little, but I think > it's more acceptable to do it for this top level call. So keep this one, but > all the others look to me like they should be returning errors. OK > >> + >> /* all points invalid */ >> bitmap_fill(st->calib_map, st->calib_map_size); >> >> @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi) >> return ret; >> >> ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev); >> - if (ret) >> + if (ret && ret != -EOPNOTSUPP) > > I don't see any modification of devm_iio_backend_request_buffer() in this > set so why why is it now acceptable to return not supported? > Given the capabilities stuff added, should this not be another capability > we check before trying to request the buffer? Basically because I reasoned that capabilities are more like features rather than single operation. The single operation tells if the capability is there. I reasoned a bit more about this in a related answer replying to Nuno, hopefully you find time to read that explanation and provide your thoughts. And reason it would now be acceptable is that the original code does not account for any optional features within the backends, but now it does. It knows it can work without the buffering, and the return value can tell if it is supported or not. Thanks, Tomas > >> return ret; >> >> ret = devm_iio_backend_enable(&spi->dev, st->back); >> >
On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote: > Add capability checks for operation with backends that do not support > full set of features, but are otherwise compatible with the device. > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com> > --- > drivers/iio/adc/ad9467.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..349779a049ad68b4c9f72abfc40154b4a3f2e095 100644 > --- a/drivers/iio/adc/ad9467.c > +++ b/drivers/iio/adc/ad9467.c > @@ -645,6 +645,9 @@ static int ad9467_backend_testmode_on(struct ad9467_state *st, > }; > int ret; > > + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) > + return 0; > + > ret = iio_backend_data_format_set(st->back, chan, &data); > if (ret) > return ret; > @@ -665,6 +668,9 @@ static int ad9467_backend_testmode_off(struct ad9467_state *st, > }; > int ret; > > + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) > + return 0; > + > ret = iio_backend_chan_disable(st->back, chan); > if (ret) > return ret; > @@ -807,6 +813,9 @@ static int ad9467_calibrate(struct ad9467_state *st) > bool invert = false, stat; > int ret; > > + if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) > + return 0; > + As David suggested, it might make more sense to do the check from the callers. Not as important as within the backend functions though. > /* all points invalid */ > bitmap_fill(st->calib_map, st->calib_map_size); > > @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi) > return ret; > > ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev); > - if (ret) > + if (ret && ret != -EOPNOTSUPP) > return ret; Don't agree with the above. I would prefer to see a dedicated CAP for buffering otherwise I would argue why not doing the same for everything? While it might be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION (given they are related to some extent), that does not apply to buffering. - Nuno Sá
Hi, On 14/01/2026 14:29, Nuno Sá wrote: > On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote: >> Add capability checks for operation with backends that do not support >> full set of features, but are otherwise compatible with the device. >> >> + return 0; >> + > > As David suggested, it might make more sense to do the check from the callers. Not as > important as within the backend functions though. > >> /* all points invalid */ >> bitmap_fill(st->calib_map, st->calib_map_size); >> >> @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi) >> return ret; >> >> ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev); >> - if (ret) >> + if (ret && ret != -EOPNOTSUPP) >> return ret; > > Don't agree with the above. I would prefer to see a dedicated CAP for buffering > otherwise I would argue why not doing the same for everything? While it might > be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION > (given they are related to some extent), that does not apply to buffering. Okay perhaps we first need to agree on how we define a capability;) So my thinking here was that calibration capability expands across several or even many op calls, so it's a feature level thing and requires several coordinated functions. So does the test pattern, but it's a sub entity of the calibration so I merged the two together. So checking for a capability in these cases makes sense, since checking against a single operation call for determining if the capability is present is not easy and which function would it be, etc. The backend buffer on the other hand maps to a single op call (in theory two). So checking for that buffering capability can be done by checking if the op call is supported (eopnotsupp). I was kindof thinking that why need a capability if the mapping is 1:1 and the information is available through that error value directly? On frontend level, like here it is known that the driver can function without that buffering, so if the backend does not supported it can be okay to proceed. If we add a capability for a single operation that has 1:1 mapping then basically we should map all and that is not really the point? I see the capability like a contract between the backend and frontend on feature level, that the feature is there but the implementation of a specific capability might actually differ depending on the use case (like we see with ad9467 and ad485x calibration and their backends) What are your thoughts about this? Thanks, Tomas > > - Nuno Sá
On Wed, 2026-01-14 at 17:23 +0200, Tomas Melin wrote: > Hi, > > On 14/01/2026 14:29, Nuno Sá wrote: > > On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote: > > > Add capability checks for operation with backends that do not support > > > full set of features, but are otherwise compatible with the device. > > > > > > > + return 0; > > > + > > > > As David suggested, it might make more sense to do the check from the callers. Not as > > important as within the backend functions though. > > > > > /* all points invalid */ > > > bitmap_fill(st->calib_map, st->calib_map_size); > > > > > > @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi) > > > return ret; > > > > > > ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev); > > > - if (ret) > > > + if (ret && ret != -EOPNOTSUPP) > > > return ret; > > > > Don't agree with the above. I would prefer to see a dedicated CAP for buffering > > otherwise I would argue why not doing the same for everything? While it might > > be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION > > (given they are related to some extent), that does not apply to buffering. > > Okay perhaps we first need to agree on how we define a capability;) > > So my thinking here was that calibration capability expands across > several or even many op calls, so it's a feature level thing and > requires several coordinated functions. So does the test pattern, but > it's a sub entity of the calibration so I merged the two together. So > checking for a capability in these cases makes sense, since checking > against a single operation call for determining if the capability is > present is not easy and which function would it be, etc. Makes sense. > > The backend buffer on the other hand maps to a single op call (in theory > two). So checking for that buffering capability can be done by checking > if the op call is supported (eopnotsupp). I was kindof thinking that why > need a capability if the mapping is 1:1 and the information is available > through that error value directly? Yeah, TBH the only reason I can think of is readability. To me, it is more explicit: if (has_buffering()) request_buffer(); //not allowed to fail And can be a bit confusing having a mix of has_capability() and checking for error codes. But yes, checking for specific error codes for determining behavior is a common pattern so I won't be nitpicky about it. > > On frontend level, like here it is known that the driver can function > without that buffering, so if the backend does not supported it can be > okay to proceed. > If we add a capability for a single operation that has 1:1 mapping then > basically we should map all and that is not really the point? > I see the capability like a contract between the backend and frontend on > feature level, that the feature is there but the implementation of a > specific capability might actually differ depending on the use case > (like we see with ad9467 and ad485x calibration and their backends) > > What are your thoughts about this? > Ok, I think it makes sense to me but maybe we should be more explicit/clear in the docs: "... meaning that a capability requires certain operations to be implemented by the backend" Maybe s/certain/multiple and we could even mention that if a frontend is interested in knowing that a operation is not supported, the error code can be checked (though this could be obvious already). Let's see what Jonathan and others thinks about it. - Nuno Sá
On Thu, 15 Jan 2026 11:54:28 +0000 Nuno Sá <noname.nuno@gmail.com> wrote: > On Wed, 2026-01-14 at 17:23 +0200, Tomas Melin wrote: > > Hi, > > > > On 14/01/2026 14:29, Nuno Sá wrote: > > > On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote: > > > > Add capability checks for operation with backends that do not support > > > > full set of features, but are otherwise compatible with the device. > > > > > > > > > > + return 0; > > > > + > > > > > > As David suggested, it might make more sense to do the check from the callers. Not as > > > important as within the backend functions though. > > > > > > > /* all points invalid */ > > > > bitmap_fill(st->calib_map, st->calib_map_size); > > > > > > > > @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi) > > > > return ret; > > > > > > > > ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev); > > > > - if (ret) > > > > + if (ret && ret != -EOPNOTSUPP) > > > > return ret; > > > > > > Don't agree with the above. I would prefer to see a dedicated CAP for buffering > > > otherwise I would argue why not doing the same for everything? While it might > > > be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION > > > (given they are related to some extent), that does not apply to buffering. > > > > Okay perhaps we first need to agree on how we define a capability;) > > > > So my thinking here was that calibration capability expands across > > several or even many op calls, so it's a feature level thing and > > requires several coordinated functions. So does the test pattern, but > > it's a sub entity of the calibration so I merged the two together. So > > checking for a capability in these cases makes sense, since checking > > against a single operation call for determining if the capability is > > present is not easy and which function would it be, etc. > > Makes sense. > > > > > The backend buffer on the other hand maps to a single op call (in theory > > two). So checking for that buffering capability can be done by checking > > if the op call is supported (eopnotsupp). I was kindof thinking that why > > need a capability if the mapping is 1:1 and the information is available > > through that error value directly? > > Yeah, TBH the only reason I can think of is readability. To me, it is more > explicit: > > if (has_buffering()) > request_buffer(); //not allowed to fail > > And can be a bit confusing having a mix of has_capability() and checking for > error codes. > > But yes, checking for specific error codes for determining behavior is a common > pattern so I won't be nitpicky about it. I'd prefer capabilities for each thing rather than a mixed scheme. Nothing wrong with also returning -ENOTSUPP if someone doesn't check the capability first as that's still helpful for debug. > > > > > On frontend level, like here it is known that the driver can function > > without that buffering, so if the backend does not supported it can be > > okay to proceed. > > If we add a capability for a single operation that has 1:1 mapping then > > basically we should map all and that is not really the point? > > > I see the capability like a contract between the backend and frontend on > > feature level, that the feature is there but the implementation of a > > specific capability might actually differ depending on the use case > > (like we see with ad9467 and ad485x calibration and their backends) > > > > What are your thoughts about this? > > > > Ok, I think it makes sense to me but maybe we should be more explicit/clear in > the docs: > > "... meaning that a capability requires certain > operations to be implemented by the backend" > > Maybe s/certain/multiple and we could even mention that if a frontend is interested > in knowing that a operation is not supported, the error code can be checked > (though this could be obvious already). > > Let's see what Jonathan and others thinks about it. > > - Nuno Sá > > > > > >
On 16/01/2026 20:32, Jonathan Cameron wrote: > On Thu, 15 Jan 2026 11:54:28 +0000 > Nuno Sá <noname.nuno@gmail.com> wrote: > >> On Wed, 2026-01-14 at 17:23 +0200, Tomas Melin wrote: >>> Hi, >>> >>> On 14/01/2026 14:29, Nuno Sá wrote: >>>> On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote: >>>>> Add capability checks for operation with backends that do not support >>>>> full set of features, but are otherwise compatible with the device. >>>>> >>> >>>>> + return 0; >>>>> + >>>> >>>> As David suggested, it might make more sense to do the check from the callers. Not as >>>> important as within the backend functions though. >>>> >>>>> /* all points invalid */ >>>>> bitmap_fill(st->calib_map, st->calib_map_size); >>>>> >>>>> @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi) >>>>> return ret; >>>>> >>>>> ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev); >>>>> - if (ret) >>>>> + if (ret && ret != -EOPNOTSUPP) >>>>> return ret; >>>> >>>> Don't agree with the above. I would prefer to see a dedicated CAP for buffering >>>> otherwise I would argue why not doing the same for everything? While it might >>>> be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION >>>> (given they are related to some extent), that does not apply to buffering. >>> >>> Okay perhaps we first need to agree on how we define a capability;) >>> >>> So my thinking here was that calibration capability expands across >>> several or even many op calls, so it's a feature level thing and >>> requires several coordinated functions. So does the test pattern, but >>> it's a sub entity of the calibration so I merged the two together. So >>> checking for a capability in these cases makes sense, since checking >>> against a single operation call for determining if the capability is >>> present is not easy and which function would it be, etc. >> >> Makes sense. >> >>> >>> The backend buffer on the other hand maps to a single op call (in theory >>> two). So checking for that buffering capability can be done by checking >>> if the op call is supported (eopnotsupp). I was kindof thinking that why >>> need a capability if the mapping is 1:1 and the information is available >>> through that error value directly? >> >> Yeah, TBH the only reason I can think of is readability. To me, it is more >> explicit: >> >> if (has_buffering()) >> request_buffer(); //not allowed to fail >> >> And can be a bit confusing having a mix of has_capability() and checking for >> error codes. >> >> But yes, checking for specific error codes for determining behavior is a common >> pattern so I won't be nitpicky about it. > > I'd prefer capabilities for each thing rather than a mixed scheme. > Nothing wrong with also returning -ENOTSUPP if someone doesn't check > the capability first as that's still helpful for debug. Okay I'll update accordingly. So capabilities are defined as being something that * is defined/added on a need basis to help frontends decide if a feature is supported * can map into multiple operations * can map to a single operation Thanks, Tomas > > >> >>> >>> On frontend level, like here it is known that the driver can function >>> without that buffering, so if the backend does not supported it can be >>> okay to proceed. >>> If we add a capability for a single operation that has 1:1 mapping then >>> basically we should map all and that is not really the point? >> >>> I see the capability like a contract between the backend and frontend on >>> feature level, that the feature is there but the implementation of a >>> specific capability might actually differ depending on the use case >>> (like we see with ad9467 and ad485x calibration and their backends) >>> >>> What are your thoughts about this? >>> >> >> Ok, I think it makes sense to me but maybe we should be more explicit/clear in >> the docs: >> >> "... meaning that a capability requires certain >> operations to be implemented by the backend" >> >> Maybe s/certain/multiple and we could even mention that if a frontend is interested >> in knowing that a operation is not supported, the error code can be checked >> (though this could be obvious already). >> >> Let's see what Jonathan and others thinks about it. >> >> - Nuno Sá >> >> >> >> >> >> > >
© 2016 - 2026 Red Hat, Inc.