| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <uwente5i2eztozco5qeaglgvtuamewytxijaqjzaaxlbvdsoyj@fuko4wpwbztl>
Date: Mon, 28 Jul 2025 16:11:28 +0100
From: Nuno Sá <noname.nuno@...il.com>
To: Ioana Risteiu <Ioana.Risteiu@...log.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
Michael Hennerich <Michael.Hennerich@...log.com>, Jonathan Cameron <jic23@...nel.org>,
David Lechner <dlechner@...libre.com>, Nuno Sá <nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Ramona Nechita <ramona.nechita@...log.com>, linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] iio: adc: Update ad7779 to use IIO backend
On Mon, Jul 28, 2025 at 04:43:36PM +0300, Ioana Risteiu wrote:
> Add a new functionality to ad7779 driver that streams data through data
> output interface using IIO backend interface.
>
> Signed-off-by: Ioana Risteiu <Ioana.Risteiu@...log.com>
> ---
> drivers/iio/adc/ad7779.c | 299 +++++++++++++++++++++++++++++++++------
> 1 file changed, 256 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/iio/adc/ad7779.c b/drivers/iio/adc/ad7779.c
> index 845adc510239..872c551eadf6 100644
> --- a/drivers/iio/adc/ad7779.c
> +++ b/drivers/iio/adc/ad7779.c
> @@ -31,6 +31,8 @@
> #include <linux/iio/triggered_buffer.h>
> #include <linux/iio/trigger_consumer.h>
>
> +#include <linux/iio/backend.h>
> +
> #define AD7779_SPI_READ_CMD BIT(7)
>
> #define AD7779_DISABLE_SD BIT(7)
> @@ -116,6 +118,12 @@
> #define AD7779_CRC8_POLY 0x07
> DECLARE_CRC8_TABLE(ad7779_crc8_table);
>
...
>
> +static const struct iio_chan_spec_ext_info ad7779_ext_info_filter[] = {
> + IIO_ENUM("data_lines", IIO_SHARED_BY_ALL, &ad7779_data_lines_enum),
> + IIO_ENUM_AVAILABLE("data_lines", IIO_SHARED_BY_ALL,
> + &ad7779_data_lines_enum),
> + IIO_ENUM("filter_type", IIO_SHARED_BY_ALL, &ad7779_filter_enum),
> + IIO_ENUM_AVAILABLE("filter_type", IIO_SHARED_BY_ALL,
> + &ad7779_filter_enum),
> + { }
> +};
> +
I guess this can get simpler... Do we really want to control data_lanes
at runtime? From my experience that's a DT parameter and it's not
something you can change at runtime. Often is a synthesis parameter on
the IP core (backend side).
> #define AD777x_CHAN_S(index, _ext_info) \
> { \
> .type = IIO_VOLTAGE, \
> @@ -669,11 +788,34 @@ static const struct iio_chan_spec_ext_info ad7779_ext_filter[] = {
> }, \
> }
>
> +#define AD777X_CHAN(index, _ext_info) \
> + { \
> + .type = IIO_VOLTAGE, \
> + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .address = (index), \
> + .indexed = 1, \
> + .channel = (index), \
> + .scan_index = (index), \
> + .ext_info = (_ext_info), \
> + .scan_type = { \
> + .sign = 's', \
> + .realbits = 24, \
> + .storagebits = 32, \
> + }, \
> + }
> +
> #define AD777x_CHAN_NO_FILTER_S(index) \
> AD777x_CHAN_S(index, NULL)
>
> +#define AD777X_CHAN_NO_FILTER(index) \
> + AD777X_CHAN(index, ad7779_ext_info)
> +
> #define AD777x_CHAN_FILTER_S(index) \
> AD777x_CHAN_S(index, ad7779_ext_filter)
> +
> +#define AD777X_CHAN_FILTER(index) \
> + AD777X_CHAN(index, ad7779_ext_info_filter)
> +
> static const struct iio_chan_spec ad7779_channels[] = {
> AD777x_CHAN_NO_FILTER_S(0),
> AD777x_CHAN_NO_FILTER_S(1),
> @@ -686,6 +828,17 @@ static const struct iio_chan_spec ad7779_channels[] = {
> IIO_CHAN_SOFT_TIMESTAMP(8),
> };
>
> +static const struct iio_chan_spec ad7779_channels_data[] = {
> + AD777X_CHAN_NO_FILTER(0),
> + AD777X_CHAN_NO_FILTER(1),
> + AD777X_CHAN_NO_FILTER(2),
> + AD777X_CHAN_NO_FILTER(3),
> + AD777X_CHAN_NO_FILTER(4),
> + AD777X_CHAN_NO_FILTER(5),
> + AD777X_CHAN_NO_FILTER(6),
> + AD777X_CHAN_NO_FILTER(7),
> +};
> +
> static const struct iio_chan_spec ad7779_channels_filter[] = {
> AD777x_CHAN_FILTER_S(0),
> AD777x_CHAN_FILTER_S(1),
> @@ -698,6 +851,17 @@ static const struct iio_chan_spec ad7779_channels_filter[] = {
> IIO_CHAN_SOFT_TIMESTAMP(8),
> };
>
> +static const struct iio_chan_spec ad7779_channels_filter_data[] = {
> + AD777X_CHAN_FILTER(0),
> + AD777X_CHAN_FILTER(1),
> + AD777X_CHAN_FILTER(2),
> + AD777X_CHAN_FILTER(3),
> + AD777X_CHAN_FILTER(4),
> + AD777X_CHAN_FILTER(5),
> + AD777X_CHAN_FILTER(6),
> + AD777X_CHAN_FILTER(7),
> +};
> +
> static const struct iio_buffer_setup_ops ad7779_buffer_setup_ops = {
> .preenable = ad7779_buffer_preenable,
> .postdisable = ad7779_buffer_postdisable,
> @@ -752,6 +916,91 @@ static int ad7779_conf(struct ad7779_state *st, struct gpio_desc *start_gpio)
> return 0;
> }
>
> +static int ad7779_register_irq(struct ad7779_state *st, struct iio_dev *indio_dev)
> +{
> + int ret;
> + struct device *dev = &st->spi->dev;
> +
> + indio_dev->info = &ad7779_info;
> + indio_dev->channels = st->chip_info->channels;
> + indio_dev->num_channels = ARRAY_SIZE(ad7779_channels);
> +
We might be able to get the above in a generic way... See below.
> + st->trig = devm_iio_trigger_alloc(dev, "%s-dev%d", indio_dev->name,
> + iio_device_id(indio_dev));
> + if (!st->trig)
> + return -ENOMEM;
> +
> + st->trig->ops = &ad7779_trigger_ops;
> +
> + iio_trigger_set_drvdata(st->trig, st);
> +
> + ret = devm_request_irq(dev, st->spi->irq, iio_trigger_generic_data_rdy_poll,
> + IRQF_ONESHOT | IRQF_NO_AUTOEN, indio_dev->name,
> + st->trig);
> + if (ret)
> + return dev_err_probe(dev, ret, "request IRQ %d failed\n",
> + st->spi->irq);
> +
> + ret = devm_iio_trigger_register(dev, st->trig);
> + if (ret)
> + return ret;
> +
> + indio_dev->trig = iio_trigger_get(st->trig);
> +
> + init_completion(&st->completion);
> +
> + ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
> + &iio_pollfunc_store_time,
> + &ad7779_trigger_handler,
> + &ad7779_buffer_setup_ops);
> + if (ret)
> + return ret;
> +
> + ret = ad7779_spi_write_mask(st, AD7779_REG_DOUT_FORMAT,
> + AD7779_DCLK_CLK_DIV_MSK,
> + FIELD_PREP(AD7779_DCLK_CLK_DIV_MSK, 7));
> + if (ret)
> + return ret;
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static int ad7779_register_back(struct ad7779_state *st, struct iio_dev *indio_dev)
> +{
> + struct device *dev = &st->spi->dev;
> + int ret = -EINVAL;
> +
> + indio_dev->info = &ad7779_info_data;
> +
> + if (strcmp(st->chip_info->name, "ad7771") == 0) {
> + indio_dev->channels = ad7779_channels_filter_data;
> + indio_dev->num_channels = ARRAY_SIZE(ad7779_channels_filter_data);
> + } else {
> + indio_dev->channels = ad7779_channels_data;
> + indio_dev->num_channels = ARRAY_SIZE(ad7779_channels_data);
> + }
I wonder if it makes sense to add a new compatible since our userspace
interface will be considerable different (similar to what was done in
[1]? This would make things easier to handle for the above. If not, I
would likely introduce a "has_filter" boolean in chip info for the
above.
> +
> + st->back = devm_iio_backend_get(dev, NULL);
> + if (IS_ERR(st->back)) {
> + dev_err_probe(dev, ret, "failed to get iio backend");
> + return PTR_ERR(st->back);
> + }
> +
> + ret = devm_iio_backend_request_buffer(dev, st->back, indio_dev);
> + if (ret)
> + return ret;
> +
> + ret = devm_iio_backend_enable(dev, st->back);
> + if (ret)
> + return ret;
> +
> + ret = iio_backend_num_lanes_set(st->back, 4);
> + if (ret)
> + return ret;
> +
> + return devm_iio_device_register(dev, indio_dev);
The above is repeated in ad7779_register_irq(). You can take it out and
do it in ad7779_probe().
> +}
> +
> static int ad7779_probe(struct spi_device *spi)
> {
> struct iio_dev *indio_dev;
> @@ -760,8 +1009,8 @@ static int ad7779_probe(struct spi_device *spi)
> struct device *dev = &spi->dev;
> int ret = -EINVAL;
>
> - if (!spi->irq)
> - return dev_err_probe(dev, ret, "DRDY irq not present\n");
The above could be a cleanup patch. I mean just drop the check and let
devm_request_irq() in case an interrupt is not present.
> + if (!spi->irq && !device_property_present(dev, "io-backends"))
> + return dev_err_probe(dev, ret, "Either DRDY interrupt or io-backends property required\n");
Then, we could just use device_property_present() to decide which
probing path to follow.
>
> indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
> if (!indio_dev)
> @@ -804,49 +1053,12 @@ static int ad7779_probe(struct spi_device *spi)
> return ret;
>
> indio_dev->name = st->chip_info->name;
> - indio_dev->info = &ad7779_info;
> indio_dev->modes = INDIO_DIRECT_MODE;
> - indio_dev->channels = st->chip_info->channels;
> - indio_dev->num_channels = ARRAY_SIZE(ad7779_channels);
> -
> - st->trig = devm_iio_trigger_alloc(dev, "%s-dev%d", indio_dev->name,
> - iio_device_id(indio_dev));
> - if (!st->trig)
> - return -ENOMEM;
> -
> - st->trig->ops = &ad7779_trigger_ops;
> -
> - iio_trigger_set_drvdata(st->trig, st);
> -
> - ret = devm_request_irq(dev, spi->irq, iio_trigger_generic_data_rdy_poll,
> - IRQF_ONESHOT | IRQF_NO_AUTOEN, indio_dev->name,
> - st->trig);
> - if (ret)
> - return dev_err_probe(dev, ret, "request IRQ %d failed\n",
> - st->spi->irq);
> -
> - ret = devm_iio_trigger_register(dev, st->trig);
> - if (ret)
> - return ret;
> -
> - indio_dev->trig = iio_trigger_get(st->trig);
> -
> - init_completion(&st->completion);
> -
> - ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
> - &iio_pollfunc_store_time,
> - &ad7779_trigger_handler,
> - &ad7779_buffer_setup_ops);
> - if (ret)
> - return ret;
>
> - ret = ad7779_spi_write_mask(st, AD7779_REG_DOUT_FORMAT,
> - AD7779_DCLK_CLK_DIV_MSK,
> - FIELD_PREP(AD7779_DCLK_CLK_DIV_MSK, 7));
> - if (ret)
> - return ret;
device_property_present> -
> - return devm_iio_device_register(dev, indio_dev);
Arguably, ad7779_register_irq() could be introduced in a precursor
patch.
> + if (spi->irq)
> + return ad7779_register_irq(st, indio_dev);
> + else
> + return ad7779_register_back(st, indio_dev);
Redundante else...
- Nuno Sá
Powered by blists - more mailing lists