From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
Lars-Peter Clausen <lars@metafoo.de>,
<linux-kernel@vger.kernel.org>, <linux-iio@vger.kernel.org>
Subject: Re: [PATCH 2/3] iio: test: test gain-time-scale helpers
Date: Mon, 15 Jan 2024 16:10:28 +0000 [thread overview]
Message-ID: <20240115161028.0000771b@Huawei.com> (raw)
In-Reply-To: <ff962e6a-5e2b-4a72-9043-80b8fc218642@gmail.com>
On Mon, 15 Jan 2024 15:01:32 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> On 1/13/24 18:12, Jonathan Cameron wrote:
> > On Wed, 10 Jan 2024 12:12:55 +0200
> > Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> >
> >> Some light sensors can adjust both the HW-gain and integration time.
> >> There are cases where adjusting the integration time has similar impact
> >> to the scale of the reported values as gain setting has.
> >>
> >> IIO users do typically expect to handle scale by a single writable 'scale'
> >> entry. Driver should then adjust the gain/time accordingly.
> >>
> >> It however is difficult for a driver to know whether it should change
> >> gain or integration time to meet the requested scale. Usually it is
> >> preferred to have longer integration time which usually improves
> >> accuracy, but there may be use-cases where long measurement times can be
> >> an issue. Thus it can be preferable to allow also changing the
> >> integration time - but mitigate the scale impact by also changing the gain
> >> underneath. Eg, if integration time change doubles the measured values,
> >> the driver can reduce the HW-gain to half.
> >>
> >> The theory of the computations of gain-time-scale is simple. However,
> >> some people (undersigned) got that implemented wrong for more than once.
> >> Hence some gain-time-scale helpers were introduced.
> >>
> >> Add some simple tests to verify the most hairy functions.
> >>
> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> >>
>
> ...
>
> >> +static void test_iio_gts_chk_scales_all(struct kunit *test, struct iio_gts *gts,
> >> + const int *vals, int len)
> >> +{
> >> + static const int gains[] = {1, 2, 4, 8, 16, 32, 64, 128, 256, 512,
> >> + 1024, 2048, 4096, 4096 * 2, 4096 * 4,
> >> + 4096 * 8};
> >> +
> >> + int expected[ARRAY_SIZE(gains) * 2];
> >> + int i, ret;
> >> + int exp_len = ARRAY_SIZE(gains) * 2;
> >
> > Use this for expected[*] just above?
>
> Doing:
> const int exp_len = ARRAY_SIZE(gains) * 2;
> int expected[exp_len];
>
> gives me:
> warning: ISO C90 forbids variable length array ‘expected’ [-Wvla]
Huh. That's a compiler being impressively stupid :(
Just leave it as it is - maybe add a comment to so no one tries to tidy this
up in future.
>
> I could drop the whole exp_len variable, but I prefer test code which is
> as obvious as it gets if any of the checks fails. For me the check:
>
> >> + KUNIT_EXPECT_EQ(test, exp_len, len);
> >> + if (len != exp_len)
> >> + return;
>
> is (very slightly) more obvious than:
> KUNIT_EXPECT_EQ(test, ARRAY_SIZE(gains) * 2, len);
> if (len != ARRAY_SIZE(gains) * 2)
> return;
>
> I guess I'll leave this one as it is. Just kick me in v2 if I
> misunderstood you :)
yeah, leave it be. Annoying but such is life.
>
> Yours,
> -- Matti
>
next prev parent reply other threads:[~2024-01-15 16:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 10:07 [PATCH 0/3] KUnit tests for the IIO GTS helpers Matti Vaittinen
2024-01-10 10:12 ` [PATCH 2/3] iio: test: test gain-time-scale helpers Matti Vaittinen
2024-01-13 16:12 ` Jonathan Cameron
2024-01-15 9:13 ` Matti Vaittinen
2024-01-15 13:01 ` Matti Vaittinen
2024-01-15 16:10 ` Jonathan Cameron [this message]
2024-01-10 10:13 ` [PATCH 3/3] MAINTAINERS: add IIO GTS tests Matti Vaittinen
2024-01-10 10:18 ` [PATCH 0/3] KUnit tests for the IIO GTS helpers Matti Vaittinen
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=20240115161028.0000771b@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=mazziesaccount@gmail.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 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.