From: Jonathan Cameron <jic23@kernel.org>
To: Giorgi Tchankvetadze <giorgitchankvetadze1997@gmail.com>
Cc: joshua.crofts1@gmail.com, dlechner@baylibre.com,
nuno.sa@analog.com, andy@kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org,
Giorgi Tchankvetadze <giorgi@tchankvetadze.com>
Subject: Re: [PATCH v2] iio: light: veml3328: reshape scale array for readability
Date: Sun, 2 Aug 2026 02:25:11 +0100 [thread overview]
Message-ID: <20260802022511.42b9e769@jic23-huawei> (raw)
In-Reply-To: <20260730082932.79484-3-giorgitchankvetadze1997@gmail.com>
On Thu, 30 Jul 2026 12:29:34 +0400
Giorgi Tchankvetadze <giorgitchankvetadze1997@gmail.com> wrote:
> From: Giorgi Tchankvetadze <giorgi@tchankvetadze.com>
>
> The veml3328_scale_vals array is declared as a flattened [4][8] array,
> so accessing a scale value requires calculating the offset of its
> (val, val2) pair using gain_inx * 2.
>
> Reshape the array as [4][4][2], with separate dimensions for integration
> time, gain and the scale value pair. This removes the manual stride
> calculation and makes the relationship between the indexes and values
> explicit.
>
> Suggested-by: David Lechner <dlechner@baylibre.com>
> Signed-off-by: Giorgi Tchankvetadze <giorgi@tchankvetadze.com>
This is good but a further suggestion below.
> ---
> Changes in v2:
> - Reshape veml3328_scale_vals as [4][4][2], as suggested by
> David Lechner.
> - Update read and write paths to access the scale value pair directly.
>
> Link to v1:
> https://lore.kernel.org/r/20260727112726.211344-1-giorgitchankvetadze1997@gmail.com
>
> drivers/iio/light/veml3328.c | 39 +++++++++++++++++++++++++++---------
> 1 file changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/light/veml3328.c b/drivers/iio/light/veml3328.c
> index 7ff1753925c4..ef0bb82e54e0 100644
> --- a/drivers/iio/light/veml3328.c
> +++ b/drivers/iio/light/veml3328.c
> @@ -91,11 +91,31 @@ static const struct iio_chan_spec veml3328_channels[] = {
> * Gain indexes: 0 (x0.5), 1 (x1), 2 (x2), 3 (x4)
> * IT indexes: 0 (50ms), 1 (100ms), 2 (200ms), 3 (400ms)
> */
> -static const int veml3328_scale_vals[4][8] = {
> - { 0, 768000, 0, 384000, 0, 192000, 0, 96000 },
> - { 0, 384000, 0, 192000, 0, 96000, 0, 48000 },
> - { 0, 192000, 0, 96000, 0, 48000, 0, 24000 },
> - { 0, 96000, 0, 48000, 0, 24000, 0, 12000 },
> +static const int veml3328_scale_vals[4][4][2] = {
> + { /* 50 ms */
Given both this and veml3328_it_times are indexing on the same thing
I wonder if it is worth
#define VEML3328_CONT_IT_50MSECS 0
#define VEML3328_CONT_IT_100MSECS 1
#define VEML3328_CONT_IT_200MSECS 2
#define VEML3328_CONT_IT_400MSECS 3
Then here use
[VEML3328_CONT_IT_50MSECS] = {
and similar for the veml3328_it_times array.
That way we keep them in sync with code rather than comments.
Jonathan
> + { 0, 768000 },
> + { 0, 384000 },
> + { 0, 192000 },
> + { 0, 96000 },
> + },
> + { /* 100 ms */
> + { 0, 384000 },
> + { 0, 192000 },
> + { 0, 96000 },
> + { 0, 48000 },
> + },
> + { /* 200 ms */
> + { 0, 192000 },
> + { 0, 96000 },
> + { 0, 48000 },
> + { 0, 24000 },
> + },
> + { /* 400 ms */
> + { 0, 96000 },
> + { 0, 48000 },
> + { 0, 24000 },
> + { 0, 12000 },
> + },
> };
>
> /* integration times in microseconds */
> @@ -184,9 +204,8 @@ static int veml3328_read_raw(struct iio_dev *indio_dev,
> if (it_inx >= ARRAY_SIZE(veml3328_it_times) || gain_inx >= 4)
> return -EINVAL;
>
> - /* Stride by 2 through the flattened array to match (val, val2) */
> - *val = veml3328_scale_vals[it_inx][gain_inx * 2];
> - *val2 = veml3328_scale_vals[it_inx][gain_inx * 2 + 1];
> + *val = veml3328_scale_vals[it_inx][gain_inx][0];
> + *val2 = veml3328_scale_vals[it_inx][gain_inx][1];
>
> return IIO_VAL_INT_PLUS_MICRO;
>
> @@ -282,8 +301,8 @@ static int veml3328_write_raw(struct iio_dev *indio_dev,
> return -EINVAL;
>
> for (i = 0; i < 4; i++) {
> - if (val == veml3328_scale_vals[it_inx][i * 2] &&
> - val2 == veml3328_scale_vals[it_inx][i * 2 + 1])
> + if (val == veml3328_scale_vals[it_inx][i][0] &&
> + val2 == veml3328_scale_vals[it_inx][i][1])
> break;
> }
>
prev parent reply other threads:[~2026-08-02 1:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 8:29 Giorgi Tchankvetadze
2026-07-30 9:06 ` Joshua Crofts
2026-08-02 1:25 ` 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=20260802022511.42b9e769@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=giorgi@tchankvetadze.com \
--cc=giorgitchankvetadze1997@gmail.com \
--cc=joshua.crofts1@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@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
all inboxes | Powered by JetHome®