From: sashiko-bot@kernel.org
To: "Rodrigo Alencar via B4 Relay"
<devnull+rodrigo.alencar.analog.com@kernel.org>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v4 06/12] iio: dac: ad5686: consume optional reset signal
Date: Tue, 23 Jun 2026 11:03:16 +0000 [thread overview]
Message-ID: <20260623110316.E2DEA1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260623-ad5686-new-features-v4-6-28962a57db0f@analog.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing power-up/reset recovery delay after reset deassertion.
- [Medium] Ignored return values from reset control operations.
--
commit 6b4f1604bc9722fb4790d1198babf7ca8eb4d482
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: dac: ad5686: consume optional reset signal
This commit adds support for an optional reset control in the probe
function. It manually generates a reset pulse after the device is
powered up.
> diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> --- a/drivers/iio/dac/ad5686.c
> +++ b/drivers/iio/dac/ad5686.c
[ ... ]
> @@ -509,6 +516,11 @@ int ad5686_probe(struct device *dev,
> /* 4.5us power-up time: Datasheet Table 4: Timing Characteristics */
> fsleep(5);
>
> + /* 1us >> 30ns reset pulse activation time: Datasheet Table 4 */
> + reset_control_assert(rstc);
> + fsleep(1);
> + reset_control_deassert(rstc);
[Severity: Medium]
Should we check the return values of reset_control_assert() and
reset_control_deassert() here?
If the reset controller is backed by a fallible bus (such as an I2C or
SPI GPIO expander), these calls can fail. If deassertion fails and the
return value is ignored, the driver might proceed while the hardware
is still stuck in reset, causing subsequent bus communications to silently
fail.
[Severity: Medium]
Does the hardware require a stabilization delay after the reset line is
deasserted before we start communicating with it?
Similar to the 4.5us power-up time handled above, if the device needs
recovery time after a hardware reset, proceeding immediately to the
initialization and first register writes might result in corrupted or
dropped commands.
> +
> /* Initialize masks to all ones */
> st->pwr_down_mask = ~0;
> st->pwr_down_mode = ~0;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-ad5686-new-features-v4-0-28962a57db0f@analog.com?part=6
next prev parent reply other threads:[~2026-06-23 11:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 10:55 [PATCH v4 00/12] New features for the AD5686 IIO driver Rodrigo Alencar via B4 Relay
2026-06-23 10:55 ` [PATCH v4 01/12] dt-bindings: iio: dac: ad5696: add reset/ldac/gain support Rodrigo Alencar via B4 Relay
2026-06-23 11:06 ` sashiko-bot
2026-06-23 10:55 ` [PATCH v4 02/12] dt-bindings: iio: dac: ad5696: rework on power supplies Rodrigo Alencar via B4 Relay
2026-06-23 13:05 ` sashiko-bot
2026-06-23 10:55 ` [PATCH v4 03/12] dt-bindings: iio: dac: ad5686: add reset/ldac/gain support Rodrigo Alencar via B4 Relay
2026-06-23 10:55 ` [PATCH v4 04/12] dt-bindings: iio: dac: ad5686: rework on power supplies Rodrigo Alencar via B4 Relay
2026-06-23 11:05 ` sashiko-bot
2026-06-23 10:55 ` [PATCH v4 05/12] iio: dac: ad5686: add support for missing " Rodrigo Alencar via B4 Relay
2026-06-23 10:55 ` [PATCH v4 06/12] iio: dac: ad5686: consume optional reset signal Rodrigo Alencar via B4 Relay
2026-06-23 11:03 ` sashiko-bot [this message]
2026-06-23 10:55 ` [PATCH v4 07/12] iio: dac: ad5686: add ldac gpio Rodrigo Alencar via B4 Relay
2026-06-23 10:55 ` [PATCH v4 08/12] iio: dac: ad5686: introduce sync operation Rodrigo Alencar via B4 Relay
2026-06-23 10:55 ` [PATCH v4 09/12] iio: dac: ad5686: implement new sync() op for the spi bus Rodrigo Alencar via B4 Relay
2026-06-23 10:55 ` [PATCH v4 10/12] iio: dac: ad5686: read_raw/write_raw: use guard(mutex)() Rodrigo Alencar via B4 Relay
2026-06-23 10:55 ` [PATCH v4 11/12] iio: dac: ad5686: add triggered buffer support Rodrigo Alencar via B4 Relay
2026-06-23 11:14 ` sashiko-bot
2026-06-23 10:55 ` [PATCH v4 12/12] iio: dac: ad5686: add gain control support Rodrigo Alencar via B4 Relay
2026-06-23 11:13 ` sashiko-bot
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=20260623110316.E2DEA1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=devnull+rodrigo.alencar.analog.com@kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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