From: "Nuno Sá" <noname.nuno@gmail.com>
To: Tomas Melin <tomas.melin@vaisala.com>,
Michael Hennerich <Michael.Hennerich@analog.com>,
Nuno Sa <nuno.sa@analog.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Jonathan Cameron <jic23@kernel.org>,
David Lechner <dlechner@baylibre.com>,
Andy Shevchenko <andy@kernel.org>,
Olivier Moysan <olivier.moysan@foss.st.com>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 4/4] iio: adc: ad9467: check for backend capabilities
Date: Tue, 03 Feb 2026 09:51:42 +0000 [thread overview]
Message-ID: <db4978d8a8c46844c6c80580af626e7340b28e1c.camel@gmail.com> (raw)
In-Reply-To: <353d33f7-995d-459d-aaaf-64bf76df7e14@vaisala.com>
On Mon, 2026-02-02 at 14:03 +0200, Tomas Melin wrote:
> Hi,
>
> On 02/02/2026 12:42, Nuno Sá wrote:
> > On Fri, 2026-01-30 at 09:17 +0000, Tomas Melin wrote:
> > > Add capability checks for operation with backends that do not necessarily
> > > support full set of features, but are otherwise compatible with the device.
> > > This ensures a fully functional device, but with limited capabilities.
> ...
> > >
> > > @@ -1263,8 +1271,10 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
> > > if (!st->chan_test)
> > > return;
> > >
> > > - debugfs_create_file("calibration_table_dump", 0400, d, st,
> > > - &ad9467_calib_table_fops);
> > > + if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> > > + debugfs_create_file("calibration_table_dump", 0400, d, st,
> > > + &ad9467_calib_table_fops);
> > > + }
> > >
> > > for (chan = 0; chan < st->info->num_channels; chan++) {
> > > snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",
> >
> > Change the permissions for in_voltage%u_test_mode so that is WO in case we can't
> > IIO_BACKEND_CAP_CALIBRATION. You can even reuse the above check to tweak the permissions
> > accordingly. Then no need to check for the capability in ad9467_chan_test_mode_read()
>
> This RO would be then only for cases PN9, PN23. For the other attributes
> RW would still be applicable. But basically I think the test modes in
> the device are still available even if the backend status does not exist?
Yeah, they are. The backend is only validating the pattern to make sure it is what's
expected. TBH, I'm not sure what's the utility without the backend but I guess one might
want to connect the interface somewhere and check the patterns.
> IMHO the current approach is slightly cleaner, as all the test modes the
> device supports are available and no need to think about which ones have
> RW/RO inside this function. Please let me know, in case you insist on
> this kind of approach.
>
>
Ok, I reviewed the code and I see we still print some running status for all the patterns.
Feel free to leave as-is then
- Nuno Sá
prev parent reply other threads:[~2026-02-03 9:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 9:16 [PATCH v5 0/4] iio: adc: ad9467: Support alternative backends Tomas Melin
2026-01-30 9:16 ` [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities Tomas Melin
2026-01-31 20:30 ` David Lechner
2026-02-02 10:28 ` Nuno Sá
2026-02-02 11:08 ` Tomas Melin
2026-02-02 12:40 ` Nuno Sá
2026-02-02 13:04 ` Tomas Melin
2026-02-02 15:50 ` David Lechner
2026-02-03 9:50 ` Tomas Melin
2026-02-04 1:07 ` David Lechner
2026-02-04 11:15 ` Tomas Melin
2026-02-03 10:01 ` Nuno Sá
2026-02-03 10:45 ` Tomas Melin
2026-02-02 10:58 ` Tomas Melin
2026-02-02 15:17 ` David Lechner
2026-01-30 9:17 ` [PATCH v5 2/4] iio: adc: adi-axi-adc: define supported iio-backend capabilities Tomas Melin
2026-02-02 10:33 ` Nuno Sá
2026-01-30 9:17 ` [PATCH v5 3/4] iio: dac: adi-axi-dac: " Tomas Melin
2026-02-02 10:33 ` Nuno Sá
2026-01-30 9:17 ` [PATCH v5 4/4] iio: adc: ad9467: check for backend capabilities Tomas Melin
2026-01-31 20:40 ` David Lechner
2026-02-02 11:18 ` Tomas Melin
2026-02-02 10:42 ` Nuno Sá
2026-02-02 12:03 ` Tomas Melin
2026-02-03 9:51 ` Nuno Sá [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=db4978d8a8c46844c6c80580af626e7340b28e1c.camel@gmail.com \
--to=noname.nuno@gmail.com \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=olivier.moysan@foss.st.com \
--cc=tomas.melin@vaisala.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®