From: Jonathan Cameron <jic23@kernel.org>
To: Antoniu Miclaus <antoniu.miclaus@analog.com>
Cc: "Michael Hennerich" <michael.hennerich@analog.com>,
"Marcelo Schmitt" <marcelo.schmitt@analog.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"David Lechner" <dlechner@baylibre.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Petre Rodan" <petre.rodan@subdimension.ro>,
"Jorge Marques" <jorge.marques@analog.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/4] iio: accel: adxl372: factor out buffer and trigger setup
Date: Sat, 21 Mar 2026 11:18:05 +0000 [thread overview]
Message-ID: <20260321111805.0acc00c6@jic23-huawei> (raw)
In-Reply-To: <20260321100729.2440-4-antoniu.miclaus@analog.com>
On Sat, 21 Mar 2026 12:04:58 +0200
Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:
> Extract the triggered buffer, trigger allocation, and IRQ request
> logic from adxl372_probe() into a dedicated adxl372_buffer_setup()
> helper. This reduces the probe function complexity and prepares for
> conditionally disabling buffer support on device variants with
> known FIFO issues.
>
> No functional change intended.
>
> Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
A couple of comments, but all about stuff you've simply moved, so not
asking for changes (though if you respin for other reasons, good
to tidy up the line wrap).
Jonathan
> ---
> Changes in v4:
> - Use 'if (ret)' instead of 'if (ret < 0)' for
> devm_iio_trigger_register() and devm_iio_triggered_buffer_setup_ext()
> return checks in adxl372_buffer_setup().
>
> drivers/iio/accel/adxl372.c | 94 ++++++++++++++++++++-----------------
> 1 file changed, 51 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index b34b91cae753..6fd4fe0ec1d9 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -1193,6 +1193,56 @@ bool adxl372_readable_noinc_reg(struct device *dev, unsigned int reg)
> }
> EXPORT_SYMBOL_NS_GPL(adxl372_readable_noinc_reg, "IIO_ADXL372");
>
> +static int adxl372_buffer_setup(struct iio_dev *indio_dev)
> +{
> + struct adxl372_state *st = iio_priv(indio_dev);
> + struct device *dev = st->dev;
> + int ret;
> +
> + ret = devm_iio_triggered_buffer_setup_ext(dev,
> + indio_dev, NULL,
Not sure why this wrapping (was in original code too)
I might move these two up a line whilst applying.
> + adxl372_trigger_handler,
> + IIO_BUFFER_DIRECTION_IN,
> + &adxl372_buffer_ops,
> + adxl372_fifo_attributes);
> + if (ret)
> + return ret;
> +
> + if (!st->irq)
> + return 0;
> +
> + st->dready_trig = devm_iio_trigger_alloc(dev, "%s-dev%d",
> + indio_dev->name,
> + iio_device_id(indio_dev));
> + if (!st->dready_trig)
> + return -ENOMEM;
> +
> + st->peak_datardy_trig = devm_iio_trigger_alloc(dev, "%s-dev%d-peak",
> + indio_dev->name,
> + iio_device_id(indio_dev));
> + if (!st->peak_datardy_trig)
> + return -ENOMEM;
> +
> + st->dready_trig->ops = &adxl372_trigger_ops;
> + st->peak_datardy_trig->ops = &adxl372_peak_data_trigger_ops;
In original code so not something to fix in this patch, but odd mix
of dready and datardy naming. I think they are both related to data
being ready. Either form is fine, but having both used in adjacent
lines of code not so much! If you have time to make that consistent
in a follow up series that would be good.
> + iio_trigger_set_drvdata(st->dready_trig, indio_dev);
> + iio_trigger_set_drvdata(st->peak_datardy_trig, indio_dev);
> + ret = devm_iio_trigger_register(dev, st->dready_trig);
> + if (ret)
> + return ret;
> +
> + ret = devm_iio_trigger_register(dev, st->peak_datardy_trig);
> + if (ret)
> + return ret;
> +
> + indio_dev->trig = iio_trigger_get(st->dready_trig);
> +
> + return devm_request_irq(dev, st->irq,
> + iio_trigger_generic_data_rdy_poll,
> + IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> + indio_dev->name, st->dready_trig);
> +}
> +
> int adxl372_probe(struct device *dev, struct regmap *regmap,
> int irq, const struct adxl372_chip_info *chip_info)
> {
> @@ -1227,52 +1277,10 @@ int adxl372_probe(struct device *dev, struct regmap *regmap,
> return ret;
> }
>
> - ret = devm_iio_triggered_buffer_setup_ext(dev,
> - indio_dev, NULL,
> - adxl372_trigger_handler,
> - IIO_BUFFER_DIRECTION_IN,
> - &adxl372_buffer_ops,
> - adxl372_fifo_attributes);
> + ret = adxl372_buffer_setup(indio_dev);
> if (ret < 0)
> return ret;
>
> - if (st->irq) {
> - st->dready_trig = devm_iio_trigger_alloc(dev,
> - "%s-dev%d",
> - indio_dev->name,
> - iio_device_id(indio_dev));
> - if (st->dready_trig == NULL)
> - return -ENOMEM;
> -
> - st->peak_datardy_trig = devm_iio_trigger_alloc(dev,
> - "%s-dev%d-peak",
> - indio_dev->name,
> - iio_device_id(indio_dev));
> - if (!st->peak_datardy_trig)
> - return -ENOMEM;
> -
> - st->dready_trig->ops = &adxl372_trigger_ops;
> - st->peak_datardy_trig->ops = &adxl372_peak_data_trigger_ops;
> - iio_trigger_set_drvdata(st->dready_trig, indio_dev);
> - iio_trigger_set_drvdata(st->peak_datardy_trig, indio_dev);
> - ret = devm_iio_trigger_register(dev, st->dready_trig);
> - if (ret < 0)
> - return ret;
> -
> - ret = devm_iio_trigger_register(dev, st->peak_datardy_trig);
> - if (ret < 0)
> - return ret;
> -
> - indio_dev->trig = iio_trigger_get(st->dready_trig);
> -
> - ret = devm_request_irq(dev, st->irq,
> - iio_trigger_generic_data_rdy_poll,
> - IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> - indio_dev->name, st->dready_trig);
> - if (ret < 0)
> - return ret;
> - }
> -
> return devm_iio_device_register(dev, indio_dev);
> }
> EXPORT_SYMBOL_NS_GPL(adxl372_probe, "IIO_ADXL372");
next prev parent reply other threads:[~2026-03-21 11:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 10:04 [PATCH v4 0/4] iio: accel: adxl372: add ADXL371 support Antoniu Miclaus
2026-03-21 10:04 ` [PATCH v4 1/4] iio: accel: adxl372: introduce chip_info structure Antoniu Miclaus
2026-03-21 11:13 ` Jonathan Cameron
2026-03-21 10:04 ` [PATCH v4 2/4] dt-bindings: iio: accel: adi,adxl372: add ADXL371 compatible Antoniu Miclaus
2026-03-21 10:04 ` [PATCH v4 3/4] iio: accel: adxl372: factor out buffer and trigger setup Antoniu Miclaus
2026-03-21 11:18 ` Jonathan Cameron [this message]
2026-03-21 10:04 ` [PATCH v4 4/4] iio: accel: adxl372: add support for ADXL371 Antoniu Miclaus
2026-03-21 11:25 ` [PATCH v4 0/4] iio: accel: adxl372: add ADXL371 support Jonathan Cameron
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=20260321111805.0acc00c6@jic23-huawei \
--to=jic23@kernel.org \
--cc=antoniu.miclaus@analog.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jorge.marques@analog.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt@analog.com \
--cc=michael.hennerich@analog.com \
--cc=nuno.sa@analog.com \
--cc=petre.rodan@subdimension.ro \
--cc=robh@kernel.org \
/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