From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Alisa-Dariana Roman <alisadariana@gmail.com>
Cc: Alisa-Dariana Roman <alisa.roman@analog.com>,
David Lechner <dlechner@baylibre.com>,
<linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
Jonathan Cameron <jic23@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH v3 0/3] Add support for AD7191
Date: Fri, 31 Jan 2025 18:26:46 +0000 [thread overview]
Message-ID: <20250131182646.000074b6@huawei.com> (raw)
In-Reply-To: <20250129143054.225322-1-alisa.roman@analog.com>
On Wed, 29 Jan 2025 16:29:01 +0200
Alisa-Dariana Roman <alisadariana@gmail.com> wrote:
> Thank you all for your feedback! Here is the updated series of patches!
>
> I addressed all the replies' points, except for the one about the size of the
> avail array being 1 when the pga/odr pins are pin-strapped. David raised a very
> good point, but, for now, I left the size fixed to 4, since the functions for
> setting the values return error anyway when they are pin-strapped.
Shouldn't have them pretending they can be changed when they can't
(which is what I think you mean about size fixed to 4). So this needs resolving.
>
> I thought of 3 approaches:
> - dynamic allocation for the avail arrays
Probably best avoided.
> - different avail array for the 2 different cases (pin-strap or gpios)
That works for me.
> - different channels array for the 2 different cases (probably too much)
It is a bit odd to list avail when only one value, but not wrong as such so
I think no need to go this far, though maybe there is a userspace library
this might confuse?
>
> If the current setup if not good enough, which approach would be the best?
>
> Kind regards,
> Alisa-Dariana Roman.
>
> ---
>
> v2: https://lore.kernel.org/all/20250122132821.126600-1-alisa.roman@analog.com/
>
> v2 -> v3:
> - correct binding title
> - remove clksel_state and clksel_gpio, assume the clksel pin is always
> pinstrapped
> - rephrase clocks description accordingly
> - simplify binding constraints
> - specify in binding description that PDOWN must be connected to SPI's
> controller's CS
> - add minItems for gpios in bindings
> - make scope explicit for mutex guard
> - remove spi irq check
> - add id_table to spi_driver struct
> - changed comments as suggested
> - use spi_message_init_with_transfers()
> - default returns an error in ad7191_set_mode()
> - replace hard-coded 2 with st->pga_gpios->ndescs
> - use gpiod_set_array_value_cansleep()
> - change .storagebits to 32
> - check return value for ad_sd_init()
> - change to adi,odr-value and adi,pga-value, which now accepts the value as
> suggested
> - modify variables names and refactor the setup of odr and pga gpios,
> indexes and available arrays into ad7191_config_setup(), since they are all
> related
> - add ad7191.rst
>
> v1: https://lore.kernel.org/all/20241221155926.81954-1-alisa.roman@analog.com/
>
> v1 -> v2:
> - removed patch adding function in ad_sigma_delta.h/.c
> - added a function set_cs() for asserting/deasserting the cs
> - handle pinstrapping cases
> - refactored all clock handling
> - updated bindings: corrected and added new things
> - -> address of the channels is used in set_channel()
> - addressed all the other changes
>
prev parent reply other threads:[~2025-01-31 18:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 14:29 [PATCH v3 0/3] Add support for AD7191 Alisa-Dariana Roman
2025-01-29 14:29 ` [PATCH v3 1/3] dt-bindings: iio: adc: add AD7191 Alisa-Dariana Roman
2025-01-29 16:51 ` Rob Herring
2025-01-29 14:29 ` [PATCH v3 2/3] iio: adc: ad7191: " Alisa-Dariana Roman
2025-01-31 18:35 ` Jonathan Cameron
2025-01-29 14:29 ` [PATCH v3 3/3] docs: iio: " Alisa-Dariana Roman
2025-01-31 18:39 ` Jonathan Cameron
2025-01-31 18:26 ` Jonathan Cameron [this message]
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=20250131182646.000074b6@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Michael.Hennerich@analog.com \
--cc=alisa.roman@analog.com \
--cc=alisadariana@gmail.com \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.