From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Marek Vasut <marex@denx.de>
Cc: <linux-iio@vger.kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Daniel Baluta <daniel.baluta@nxp.com>
Subject: Re: [PATCH v3 10/10] iio: adc: ti-ads1015: Switch to read_avail
Date: Tue, 22 Mar 2022 21:15:05 +0000 [thread overview]
Message-ID: <20220322211505.000020f1@Huawei.com> (raw)
In-Reply-To: <20220320181428.168109-10-marex@denx.de>
On Sun, 20 Mar 2022 19:14:28 +0100
Marek Vasut <marex@denx.de> wrote:
> Replace sysfs attributes with read_avail() callback. This also permits
> removal of ads1115_info, since the scale attribute tables are now part
> of chip data.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
> Cc: Daniel Baluta <daniel.baluta@nxp.com>
> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> V3: New patch
> ---
> drivers/iio/adc/ti-ads1015.c | 102 +++++++++++++++++++----------------
> 1 file changed, 57 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> index 66431d1445d9b..b1257f65d7431 100644
> --- a/drivers/iio/adc/ti-ads1015.c
> +++ b/drivers/iio/adc/ti-ads1015.c
> @@ -81,6 +81,9 @@ struct ads1015_chip_data {
> int num_channels;
> const struct iio_info *info;
> const unsigned int *data_rate;
Should probably change this to signed.
> + const unsigned int data_rate_len;
> + const unsigned int *scale;
Why unsigned int given we use it as an array of signed ints?
> + const unsigned int scale_len;
> bool has_comparator;
> };
>
> @@ -108,10 +111,18 @@ static const unsigned int ads1115_data_rate[] = {
> * Translation from PGA bits to full-scale positive and negative input voltage
> * range in mV
> */
> -static int ads1015_fullscale_range[] = {
> +static const int ads1015_fullscale_range[] = {
Technically unrelated but good fix and not hurting patch readability significantly
so perhaps not worth a separate patch.
> 6144, 4096, 2048, 1024, 512, 256, 256, 256
> };
>
> +static const int ads1015_scale[] = { /* 12bit ADC */
> + 256, 11, 512, 11, 1024, 11, 2048, 11, 4096, 11, 6144, 11
I wonder if it's worth either using a 2D array and casting
a dimension away, or perhaps just formatting these pair wise
so we can see what is going on more obviously?
I don't feel strongly about this so up to you.
> +};
> +
> +static const int ads1115_scale[] = { /* 16bit ADC */
> + 256, 15, 512, 15, 1024, 15, 2048, 15, 4096, 15, 6144, 15
> +};
next prev parent reply other threads:[~2022-03-22 21:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-20 18:14 [PATCH v3 01/10] dt-bindings: iio: adc: ti,ads1015: Add missing ADS1115 compatible string Marek Vasut
2022-03-20 18:14 ` [PATCH v3 02/10] dt-bindings: iio: adc: ti,ads1015: Add TLA2024 " Marek Vasut
2022-03-20 18:14 ` [PATCH v3 03/10] iio: adc: ti-ads1015: Switch to static const writeable ranges table Marek Vasut
2022-03-20 18:14 ` [PATCH v3 04/10] iio: adc: ti-ads1015: Deduplicate channel macros Marek Vasut
2022-03-20 18:14 ` [PATCH v3 05/10] iio: adc: ti-ads1015: Make channel event_spec optional Marek Vasut
2022-03-20 18:14 ` [PATCH v3 06/10] iio: adc: ti-ads1015: Add TLA2024 support Marek Vasut
2022-03-20 18:14 ` [PATCH v3 07/10] iio: adc: ti-ads1015: Add static assert to test if shifted realbits fit into storagebits Marek Vasut
2022-03-20 18:14 ` [PATCH v3 08/10] iio: adc: ti-ads1015: Convert to OF match data Marek Vasut
2022-03-21 9:24 ` Andy Shevchenko
2022-03-22 21:00 ` Jonathan Cameron
2022-03-22 21:41 ` Marek Vasut
2022-03-20 18:14 ` [PATCH v3 09/10] iio: adc: ti-ads1015: Replace data_rate with chip data struct ads1015_data Marek Vasut
2022-03-21 9:26 ` Andy Shevchenko
2022-03-21 14:41 ` Marek Vasut
2022-03-21 16:17 ` Andy Shevchenko
2022-03-22 20:48 ` Jonathan Cameron
2022-03-20 18:14 ` [PATCH v3 10/10] iio: adc: ti-ads1015: Switch to read_avail Marek Vasut
2022-03-21 9:27 ` Andy Shevchenko
2022-03-21 14:44 ` Marek Vasut
2022-03-21 16:19 ` Andy Shevchenko
2022-03-21 19:46 ` Marek Vasut
2022-03-22 20:50 ` Jonathan Cameron
2022-03-22 21:15 ` Jonathan Cameron [this message]
2022-03-22 21:39 ` Marek Vasut
2022-03-22 22:03 ` Marek Vasut
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=20220322211505.000020f1@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=daniel.baluta@nxp.com \
--cc=linux-iio@vger.kernel.org \
--cc=marex@denx.de \
/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.