public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Rodrigo Alencar via B4 Relay
	<devnull+rodrigo.alencar.analog.com@kernel.org>
Cc: rodrigo.alencar@analog.com, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Stefan Popa <stefan.popa@analog.com>,
	Jonathan Cameron <jic23@cam.ac.uk>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Michael Auchter <michael.auchter@ni.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	David Lechner <dlechner@baylibre.com>,
	Andy Shevchenko <andy@kernel.org>
Subject: Re: [PATCH v3 04/11] iio: dac: ad5686: fix powerdown control on dual-channel devices
Date: Wed, 29 Apr 2026 11:07:50 +0100	[thread overview]
Message-ID: <20260429110750.2cab924b@jic23-huawei> (raw)
In-Reply-To: <20260428-ad5686-fixes-v3-4-9cff7bd67a15@analog.com>

On Tue, 28 Apr 2026 18:02:19 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:

> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> 
> Fix powerdown control by using a proper bit shift for the powerdown mask
> values. During initialization, powerdown bits are initialized so that
> unused bits are set to 1 and the correct bit shift is used. Dual-channel
> devices use one-hot encoding in the address and that reflects on the
> position of the powerdown bits, which are not channel-index based
> for that case. Quad-channel devices also use one-hot encoding for the
> channel address but the result of log2(address) coincides with the channel
> index value. The issue was introduced when first adding support for
> dual-channel devices, which overlooked powerdown control differences.
> 
> Fixes: 7dc8faeab3e3 ("iio: dac: ad5686: add support for AD5338R")
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Backed this one out again for now.  See sashiko review.
https://sashiko.dev/#/patchset/20260428-ad5686-fixes-v3-0-9cff7bd67a15%40analog.com

I took a look at the ad5310r (unhelpfully called ad5310 in the
majority of the driver - something it would be nice to fix!)
and there are some real oddities when comparing what we send
to that device with the datasheet.

Understanding not helped by the bit numbering changing on the
datasheet between tables 10 and 11 :( Feel free to suggest they fix that!

Anyhow, I think sashiko is correct and the stray 1111b will corrupt
the command bits and maybe even the reset.

I haven't yet asked for sashiko reviews to just be sent to the mailing
list, as I'm still personally getting comfortable with how accurate they
are - but I'm thinking about it. In meantime please do take a look
at them as they catch things like this (assuming it is real!)

Jonathan


> ---
>  drivers/iio/dac/ad5686.c | 37 +++++++++++++++++++++++++++----------
>  1 file changed, 27 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> index 69358dd66cbc..b31d0ec5415c 100644
> --- a/drivers/iio/dac/ad5686.c
> +++ b/drivers/iio/dac/ad5686.c
> @@ -25,24 +25,35 @@ static const char * const ad5686_powerdown_modes[] = {
>  	"three_state"
>  };
>  
> +static inline unsigned int ad5686_pd_mask_shift(const struct iio_chan_spec *chan)
> +{
> +	if (chan->channel == chan->address)
> +		return chan->channel * 2;
> +
> +	/* one-hot encoding is used in dual/quad channel devices */
> +	return __ffs(chan->address) * 2;
> +}
> +
>  static int ad5686_get_powerdown_mode(struct iio_dev *indio_dev,
>  				     const struct iio_chan_spec *chan)
>  {
> +	unsigned int shift = ad5686_pd_mask_shift(chan);
>  	struct ad5686_state *st = iio_priv(indio_dev);
>  
> -	return ((st->pwr_down_mode >> (chan->channel * 2)) & 0x3) - 1;
> +	return ((st->pwr_down_mode >> shift) & 0x3) - 1;
>  }
>  
>  static int ad5686_set_powerdown_mode(struct iio_dev *indio_dev,
>  				     const struct iio_chan_spec *chan,
>  				     unsigned int mode)
>  {
> +	unsigned int shift = ad5686_pd_mask_shift(chan);
>  	struct ad5686_state *st = iio_priv(indio_dev);
>  
>  	guard(mutex)(&st->lock);
>  
> -	st->pwr_down_mode &= ~(0x3 << (chan->channel * 2));
> -	st->pwr_down_mode |= ((mode + 1) << (chan->channel * 2));
> +	st->pwr_down_mode &= ~(0x3 << shift);
> +	st->pwr_down_mode |= (mode + 1) << shift;
>  
>  	return 0;
>  }
> @@ -57,10 +68,10 @@ static const struct iio_enum ad5686_powerdown_mode_enum = {
>  static ssize_t ad5686_read_dac_powerdown(struct iio_dev *indio_dev,
>  		uintptr_t private, const struct iio_chan_spec *chan, char *buf)
>  {
> +	unsigned int shift = ad5686_pd_mask_shift(chan);
>  	struct ad5686_state *st = iio_priv(indio_dev);
>  
> -	return sysfs_emit(buf, "%d\n", !!(st->pwr_down_mask &
> -				       (0x3 << (chan->channel * 2))));
> +	return sysfs_emit(buf, "%d\n", !!(st->pwr_down_mask & (0x3 << shift)));
>  }
>  
>  static ssize_t ad5686_write_dac_powerdown(struct iio_dev *indio_dev,
> @@ -82,9 +93,9 @@ static ssize_t ad5686_write_dac_powerdown(struct iio_dev *indio_dev,
>  	guard(mutex)(&st->lock);
>  
>  	if (readin)
> -		st->pwr_down_mask |= (0x3 << (chan->channel * 2));
> +		st->pwr_down_mask |= 0x3 << ad5686_pd_mask_shift(chan);
>  	else
> -		st->pwr_down_mask &= ~(0x3 << (chan->channel * 2));
> +		st->pwr_down_mask &= ~(0x3 << ad5686_pd_mask_shift(chan));
>  
>  	switch (st->chip_info->regmap_type) {
>  	case AD5310_REGMAP:
> @@ -464,7 +475,7 @@ int ad5686_probe(struct device *dev,
>  {
>  	struct ad5686_state *st;
>  	struct iio_dev *indio_dev;
> -	unsigned int val, ref_bit_msk;
> +	unsigned int val, ref_bit_msk, shift;
>  	bool has_external_vref;
>  	u8 cmd;
>  	int ret, i;
> @@ -489,8 +500,14 @@ int ad5686_probe(struct device *dev,
>  	st->vref_mv = has_external_vref ? ret / 1000 : st->chip_info->int_vref_mv;
>  
>  	/* Set all the power down mode for all channels to 1K pulldown */
> -	for (i = 0; i < st->chip_info->num_channels; i++)
> -		st->pwr_down_mode |= (0x01 << (i * 2));
> +	st->pwr_down_mode = ~0U;
> +	st->pwr_down_mask = ~0U;
> +	for (i = 0; i < st->chip_info->num_channels; i++) {
> +		shift = ad5686_pd_mask_shift(&st->chip_info->channels[i]);
> +		st->pwr_down_mask &= ~(0x3 << shift); /* powered up state */
> +		st->pwr_down_mode &= ~(0x3 << shift);
> +		st->pwr_down_mode |= 0x01 << shift;
> +	}
>  
>  	indio_dev->name = name;
>  	indio_dev->info = &ad5686_info;
> 


  reply	other threads:[~2026-04-29 10:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-28 17:02 [PATCH v3 00/11] Fixes and cleanups for the AD5686 IIO driver Rodrigo Alencar via B4 Relay
2026-04-28 17:02 ` [PATCH v3 01/11] iio: dac: ad5686: fix ref bit initialization for single-channel parts Rodrigo Alencar via B4 Relay
2026-04-28 17:02 ` [PATCH v3 02/11] iio: dac: ad5686: fix input raw value check Rodrigo Alencar via B4 Relay
2026-04-28 17:02 ` [PATCH v3 03/11] iio: dac: ad5686: acquire lock when doing powerdown control Rodrigo Alencar via B4 Relay
2026-04-28 17:02 ` [PATCH v3 04/11] iio: dac: ad5686: fix powerdown control on dual-channel devices Rodrigo Alencar via B4 Relay
2026-04-29 10:07   ` Jonathan Cameron [this message]
2026-04-29 10:33     ` Rodrigo Alencar
2026-04-28 17:02 ` [PATCH v3 05/11] iio: dac: ad5686: refactor include headers Rodrigo Alencar via B4 Relay
2026-04-29 10:11   ` Jonathan Cameron
2026-04-28 17:02 ` [PATCH v3 06/11] iio: dac: ad5686: remove redundant register definition Rodrigo Alencar via B4 Relay
2026-04-28 17:02 ` [PATCH v3 07/11] iio: dac: ad5686: drop enum id Rodrigo Alencar via B4 Relay
2026-04-28 17:02 ` [PATCH v3 08/11] iio: dac: ad5686: add of_match table to the spi driver Rodrigo Alencar via B4 Relay
2026-04-28 17:02 ` [PATCH v3 09/11] iio: dac: ad5686: add control_sync() for single-channel devices Rodrigo Alencar via B4 Relay
2026-04-28 17:02 ` [PATCH v3 10/11] iio: dac: ad5686: cleanup doc header of local structs Rodrigo Alencar via B4 Relay
2026-04-28 17:02 ` [PATCH v3 11/11] iio: dac: ad5686: create bus ops struct Rodrigo Alencar via B4 Relay
2026-04-29  6:36 ` [PATCH v3 00/11] Fixes and cleanups for the AD5686 IIO driver Andy Shevchenko
2026-04-29  9:36 ` 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=20260429110750.2cab924b@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=andy@kernel.org \
    --cc=devnull+rodrigo.alencar.analog.com@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=gregkh@suse.de \
    --cc=jic23@cam.ac.uk \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.auchter@ni.com \
    --cc=rodrigo.alencar@analog.com \
    --cc=stefan.popa@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