From: Alexandru Ardelean <aardelean@baylibre.com>
To: David Lechner <dlechner@baylibre.com>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, jic23@kernel.org,
krzk+dt@kernel.org, robh@kernel.org, lars@metafoo.de,
michael.hennerich@analog.com, gstols@baylibre.com
Subject: Re: [PATCH 3/6] iio: adc: ad7606: use realbits for sign-extending in scan_direct
Date: Tue, 22 Oct 2024 09:09:45 +0300 [thread overview]
Message-ID: <CA+GgBR-eKUir7FGOfimv0rE2yP3P3awMZSG8=6t202GAthi=Mg@mail.gmail.com> (raw)
In-Reply-To: <f319c8bd-1edc-451b-aeb2-27ec529267a3@baylibre.com>
On Mon, Oct 21, 2024 at 8:19 PM David Lechner <dlechner@baylibre.com> wrote:
>
> On 10/21/24 8:02 AM, Alexandru Ardelean wrote:
> > Currently the 'ad7606' driver supports parts with 18 and 16 bits
> > resolutions.
> > But when adding support for AD7607 (which has a 14-bit resolution) we
> > should check for the 'realbits' field, to be able to sign-extend correctly.
> >
> > Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
> > ---
> > drivers/iio/adc/ad7606.c | 24 +++++++++++++++++++-----
> > 1 file changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
> > index d0fe9fd65f3f..a1f0c2feb04a 100644
> > --- a/drivers/iio/adc/ad7606.c
> > +++ b/drivers/iio/adc/ad7606.c
> > @@ -568,7 +568,7 @@ static int ad7606_scan_direct(struct iio_dev *indio_dev, unsigned int ch,
> > int *val)
> > {
> > struct ad7606_state *st = iio_priv(indio_dev);
> > - unsigned int storagebits = st->chip_info->channels[1].scan_type.storagebits;
> > + unsigned int realbits = st->chip_info->channels[1].scan_type.realbits;
> > const struct iio_chan_spec *chan;
> > int ret;
> >
> > @@ -603,15 +603,29 @@ static int ad7606_scan_direct(struct iio_dev *indio_dev, unsigned int ch,
> >
> > chan = &indio_dev->channels[ch + 1];
> > if (chan->scan_type.sign == 'u') {
> > - if (storagebits > 16)
>
> I think it would be simpler to keep this if statement for choosing
> which data.bufXX to use since there are only 2 choices.
>
>
> > + switch (realbits) {
> > + case 18:
> > *val = st->data.buf32[ch];
> > - else
> > + break;
> > + case 16:
> > *val = st->data.buf16[ch];
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + break;
> > + }
> > } else {
> > - if (storagebits > 16)
> > + switch (realbits) {
> > + case 18:
> > *val = sign_extend32(st->data.buf32[ch], 17);
> > - else
> > + break;
> > + case 16:
> > *val = sign_extend32(st->data.buf16[ch], 15);
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + break;
> > + }
>
> We can change this to:
>
> *val = sign_extend32(st->data.buf16[ch], reablbits - 1);
>
> Then no additional changes should be needed to support 14-bit chips.
>
> And similarly, we could avoid the need to use the more verbose
> switch statement.
Ack.
>
> > }
> >
> > error_ret:
>
>
next prev parent reply other threads:[~2024-10-22 6:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 13:02 [PATCH 0/6] iio: adc: ad7606: add support for AD760{7,8,9} parts Alexandru Ardelean
2024-10-21 13:02 ` [PATCH 1/6] iio: adc: ad7606: fix/persist oversampling_ratio setting Alexandru Ardelean
2024-10-21 13:02 ` [PATCH 2/6] iio: adc: ad7606: fix issue/quirk with find_closest() for oversampling Alexandru Ardelean
2024-10-21 19:03 ` David Lechner
2024-10-21 19:31 ` David Lechner
2024-10-22 6:31 ` Alexandru Ardelean
2024-10-22 8:24 ` Nuno Sá
2024-10-21 13:02 ` [PATCH 3/6] iio: adc: ad7606: use realbits for sign-extending in scan_direct Alexandru Ardelean
2024-10-21 17:19 ` David Lechner
2024-10-22 6:09 ` Alexandru Ardelean [this message]
2024-10-21 13:02 ` [PATCH 4/6] iio: adc: ad7606: rework scale-available to be static Alexandru Ardelean
2024-10-21 18:17 ` David Lechner
2024-10-22 6:59 ` Alexandru Ardelean
2024-10-22 8:28 ` Nuno Sá
2024-10-21 13:02 ` [PATCH 5/6] dt-bindings: iio: adc: adi,ad7606: document AD760{7,8,9} parts Alexandru Ardelean
2024-10-21 16:52 ` Conor Dooley
2024-10-21 13:02 ` [PATCH 6/6] iio: adc: ad7606: add support for " Alexandru Ardelean
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='CA+GgBR-eKUir7FGOfimv0rE2yP3P3awMZSG8=6t202GAthi=Mg@mail.gmail.com' \
--to=aardelean@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=gstols@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.hennerich@analog.com \
--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;
as well as URLs for NNTP newsgroup(s).