From: "Nuno Sá" <noname.nuno@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: rodrigo.alencar@analog.com,
Michael Auchter <michael.auchter@ni.com>,
linux@analog.com, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org,
Michael Hennerich <Michael.Hennerich@analog.com>,
David Lechner <dlechner@baylibre.com>,
Andy Shevchenko <andy@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>
Subject: Re: [PATCH 06/12] iio: dac: ad5686: consume optional reset signal
Date: Mon, 8 Jun 2026 09:29:07 +0100 [thread overview]
Message-ID: <aiZ7mVMImugYwOVq@nsa> (raw)
In-Reply-To: <20260603130833.007c1526@jic23-huawei>
On Wed, Jun 03, 2026 at 01:08:33PM +0100, Jonathan Cameron wrote:
> On Wed, 3 Jun 2026 09:28:26 +0100
> Nuno Sá <noname.nuno@gmail.com> wrote:
>
> > On Tue, Jun 02, 2026 at 05:33:53PM +0100, Rodrigo Alencar via B4 Relay wrote:
> > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > >
> > > Add RESET pin GPIO support through an optional reset control, which is
> > > local to the probe function. Also, include delays for power-up time and
> > > reset pulse width.
> > >
> > > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > > ---
> > > drivers/iio/dac/ad5686.c | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> > > index 4a8c587ff116..345ca2436332 100644
> > > --- a/drivers/iio/dac/ad5686.c
> > > +++ b/drivers/iio/dac/ad5686.c
> > > @@ -8,12 +8,14 @@
> > > #include <linux/array_size.h>
> > > #include <linux/bitfield.h>
> > > #include <linux/bitops.h>
> > > +#include <linux/delay.h>
> > > #include <linux/dev_printk.h>
> > > #include <linux/errno.h>
> > > #include <linux/export.h>
> > > #include <linux/kstrtox.h>
> > > #include <linux/module.h>
> > > #include <linux/regulator/consumer.h>
> > > +#include <linux/reset.h>
> > > #include <linux/sysfs.h>
> > > #include <linux/wordpart.h>
> > >
> > > @@ -471,6 +473,7 @@ int ad5686_probe(struct device *dev,
> > > const struct ad5686_chip_info *chip_info,
> > > const char *name, const struct ad5686_bus_ops *ops)
> > > {
> > > + struct reset_control *rstc;
> > > struct ad5686_state *st;
> > > struct iio_dev *indio_dev;
> > > int ret, i;
> > > @@ -506,6 +509,16 @@ int ad5686_probe(struct device *dev,
> > > return dev_err_probe(dev, -EINVAL,
> > > "invalid or not provided vref voltage\n");
> > >
> > > + rstc = devm_reset_control_get_optional_exclusive(dev, NULL);
> > > + if (IS_ERR(rstc))
> > > + return dev_err_probe(dev, PTR_ERR(rstc),
> > > + "Failed to get reset control\n");
> >
> > On top of what Andy stated, I'm fairly sure
> > devm_reset_control_get_optional_exclusive() returns with the GPIO
> > asserted.
>
> We've been getting reports on that not being the case from Sashiko
> and when I last looked into one of those it definitely isn't documented
> as doing so and I got the impression it is a reset controller specific
> thing. Do we are fine here because the gpio reset controller reset_gpio_probe()
> includes:
> priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> if (IS_ERR(priv->reset))
> return dev_err_probe(dev, PTR_ERR(priv->reset),
> "Could not get reset gpios\n");
> Which I guess puts it in to reset?
>
> So do we assume gpio reset or not for this sort of driver that specifies
> in the binding reset-gpios. Now if the following is implying we need
> a deasserted to asserted transition (maybe?) then we'd need to force
> a deassert first.
Yeah, fair enough. I think in practice it works but we are relying in
internals of other piece of code for it to work which is not great.
- Nuno Sá
>
> Btw I used claude to explore this and it hallucinated the reverse polarity
> providing otherwise correct code for what was in reset_gpio_probe() but
> oddly editing that one line. I was being lazy and using the web UI rather
> than a version with access to my git tree so maybe it scraped some
> buggy code from a downstream tree. Anyhow watch out for subtle garbage!
> It also took a few requests to get it to figure out the logical nature
> of the GPIO signals rather than assuming they were controlling whether
> the line was high or low directly.
>
> Jonathan
>
>
> >
> > > +
> > > + udelay(5); /* power-up time */
> > > + reset_control_assert(rstc);
> > > + udelay(1); /* reset pulse: comfortably bigger than the spec */
> > > + reset_control_deassert(rstc);
> > > +
> > > /* Initialize masks to all ones */
> > > st->pwr_down_mask = ~0;
> > > st->pwr_down_mode = ~0;
> > >
> > > --
> > > 2.43.0
> > >
> > >
>
next prev parent reply other threads:[~2026-06-08 8:28 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 16:33 [PATCH 00/12] New features for the AD5686 IIO driver Rodrigo Alencar via B4 Relay
2026-06-02 16:33 ` [PATCH 01/12] dt-bindings: iio: dac: ad5696: add reset/ldac/gain gpio support Rodrigo Alencar via B4 Relay
2026-06-02 16:33 ` [PATCH 02/12] dt-bindings: iio: dac: ad5696: rework on power supplies Rodrigo Alencar via B4 Relay
2026-06-03 15:25 ` Conor Dooley
2026-06-02 16:33 ` [PATCH 03/12] dt-bindings: iio: dac: ad5686: add reset/ldac/gain gpio support Rodrigo Alencar via B4 Relay
2026-06-02 16:33 ` [PATCH 04/12] dt-bindings: iio: dac: ad5686: rework on power supplies Rodrigo Alencar via B4 Relay
2026-06-03 15:29 ` Conor Dooley
2026-06-02 16:33 ` [PATCH 05/12] iio: dac: ad5686: add support for missing " Rodrigo Alencar via B4 Relay
2026-06-02 19:02 ` Andy Shevchenko
2026-06-03 12:17 ` Rodrigo Alencar
2026-06-04 5:51 ` Andy Shevchenko
2026-06-02 16:33 ` [PATCH 06/12] iio: dac: ad5686: consume optional reset signal Rodrigo Alencar via B4 Relay
2026-06-02 19:03 ` Andy Shevchenko
2026-06-03 8:28 ` Nuno Sá
2026-06-03 12:08 ` Jonathan Cameron
2026-06-03 12:57 ` Philipp Zabel
2026-06-08 8:29 ` Nuno Sá [this message]
2026-06-02 16:33 ` [PATCH 07/12] iio: dac: ad5686: add ldac gpio Rodrigo Alencar via B4 Relay
2026-06-02 19:05 ` Andy Shevchenko
2026-06-02 16:33 ` [PATCH 08/12] iio: dac: ad5686: introduce sync operation Rodrigo Alencar via B4 Relay
2026-06-02 16:33 ` [PATCH 09/12] iio: dac: ad5686: implement new sync() op for the spi bus Rodrigo Alencar via B4 Relay
2026-06-02 19:14 ` Andy Shevchenko
2026-06-03 12:26 ` Rodrigo Alencar
2026-06-03 12:55 ` Jonathan Cameron
2026-06-04 19:51 ` Andy Shevchenko
2026-06-03 12:24 ` Jonathan Cameron
2026-06-02 16:33 ` [PATCH 10/12] iio: dac: ad5686: add triggered buffer support Rodrigo Alencar via B4 Relay
2026-06-02 19:18 ` Andy Shevchenko
2026-06-03 12:41 ` Jonathan Cameron
2026-06-05 11:34 ` Rodrigo Alencar
2026-06-05 14:09 ` Jonathan Cameron
2026-06-05 14:40 ` Rodrigo Alencar
2026-06-02 16:33 ` [PATCH 11/12] iio: dac: ad5686: write_raw: use guard(mutex)() Rodrigo Alencar via B4 Relay
2026-06-02 19:20 ` Andy Shevchenko
2026-06-02 16:33 ` [PATCH 12/12] iio: dac: ad5686: add gain control support Rodrigo Alencar via B4 Relay
2026-06-02 19:25 ` Andy Shevchenko
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=aiZ7mVMImugYwOVq@nsa \
--to=noname.nuno@gmail.com \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=gustavoars@kernel.org \
--cc=jic23@kernel.org \
--cc=kees@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@analog.com \
--cc=michael.auchter@ni.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=rodrigo.alencar@analog.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