From: Andrea Merello <andrea.merello@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
linux-iio <linux-iio@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Rob Herring <robh+dt@kernel.org>,
Matt Ranostay <matt.ranostay@konsulko.com>,
Alexandru Ardelean <ardeleanalex@gmail.com>,
jmondi <jacopo@jmondi.org>,
Andrea Merello <andrea.merello@iit.it>
Subject: Re: [v5 08/14] iio: imu: add Bosch Sensortec BNO055 core driver
Date: Mon, 2 May 2022 11:50:47 +0200 [thread overview]
Message-ID: <CAN8YU5PzwmeQ9XA3qod7HejG6cCLCrPvda5eomCh5hUze_DWcA@mail.gmail.com> (raw)
In-Reply-To: <CAHp75VdLiBkg100UjFN36rW_vaOObOoJ_Mv9n=4LjSWb+dQWMw@mail.gmail.com>
Il giorno mer 27 apr 2022 alle ore 15:23 Andy Shevchenko
<andy.shevchenko@gmail.com> ha scritto:
>
As usual, some inline comments. OK for the rest.
[...]
>
> > +#define BNO055_ATTR_VALS(...) \
> > + .vals = (int[]){ __VA_ARGS__}, \
> > + .len = ARRAY_SIZE(((int[]){__VA_ARGS__}))
>
> Not sure this adds any readability to the code. Can we simply have an
> array of int for each case with the explicit ARRAY_SIZE() calls?
Do you mean moving the vals array out of the structs? Something like:
static int bno055_gyr_scale_vals[] = {125, 1877467, 250, 1877467,
500, 1877467, 1000, 1877467, 2000, 1877467};
static struct bno055_sysfs_attr_aux_data bno055_gyr_scale_aux = {
.fusion_vals = (int[]){1, 900},
.hw_xlate = (int[]){4, 3, 2, 1, 0},
.type = IIO_VAL_FRACTIONAL
?
But then I'd make also something like:
#define bno055_sysfs_attr_avail(priv, attr, vals, len) \
_bno055_sysfs_attr_avail(priv, attr##_vals,
ARRAY_SIZE(attr##_vals), attr##_aux, vals, len)
And the same for all other users of those structs.
My point is not about readability, but about avoiding as much as
possible bugs caused by mismatched attr_vals, attr_aux and
ARRAY_SIZE() arg. e.g:
bno055_sysfs_attr_avail(priv, bno_foo_vals, ARRAY_SIZE(bno_bar_vals),
bno_foobar_aux, vals, len)
I used to make quite a lot of mess until I grouped all the stuff in
one struct :/
[...]
>
> > + msleep(20);
>
> Perhaps a comment why so long sleep is needed.
DS says that switching mode can last from 7mS up to 19mS depending on
the case, but I don't know _why_ it takes so long. I may add a comment
that just states that it's a sensor requirement.
[...]
>
> > + for (i = 0; i < bno055_acc_range.len; i++)
> > + len += sysfs_emit_at(buf, len, "%d%c", bno055_acc_range.vals[i],
> > + (i == bno055_acc_range.len - 1) ? '\n' : ' ');
>
> You may move the condition out of the loop.
May you elaborate, please? Do you mean something like: loop one time
less, and then call sysfs_emit_at() once more outside the loop,
getting rid of the conditional ternary operator at all?
[...]
> > + if (indio_dev->active_scan_mask &&
> > + !bitmap_empty(indio_dev->active_scan_mask, _BNO055_SCAN_MAX))
> > + return -EBUSY;
> > +
> > + if (sysfs_streq(buf, "0")) {
> > + ret = bno055_operation_mode_set(priv, BNO055_OPR_MODE_AMG);
>
> return bno055_operation_mode_set(...);
Why? bno055_operation_mode_set() returns an error code, while here we
need to return the len, or propagate the error code only when it's the
case
> > + } else {
>
> ...and drop this with the following decreasing indentation.
if you want to drop this, then I can just duplicate if(ret) return
ret; i.e. add it after bno055_operation_mode_set(priv,
BNO055_OPR_MODE_AMG); and get rid of the else branch (see above)
[...]
>
> Can be removed to group all related checks together.
I'm not sure what you mean here, but see below
> > + if (ret)
> > + dev_notice(dev, "Calibration file load failed. See instruction in kernel Documentation/iio/bno055.rst");
> > +
> > + if (caldata) {
> > + caldata_data = caldata->data;
> > + caldata_size = caldata->size;
> > + }
> > + ret = bno055_init(priv, caldata_data, caldata_size);
>
> > + if (caldata)
> > + release_firmware(caldata);
>
> > + if (ret)
> > + return ret;
>
> Can be rewritten in a form of
>
> if (caldata) {
> ret = bno055_init();
> release_firmware(...);
> } else {
> ret = bno055_init();
> }
> if (ret)
> return ret;
>
> ?
Indeed I'd say it could be rewritten as:
if (ret)
ret = request_firmware(&caldata, BNO055_FW_GENERIC_NAME, dev);
if (ret) {
dev_notice(dev, "Calibration file load failed. See
instruction in kernel Documentation/iio/bno055.rst");
ret = bno055_init(priv, NULL, 0);
} else {
ret = bno055_init(priv, caldata->data, caldata->size);
release_firmware(caldata);
}
if (ret)
return ret;
next prev parent reply other threads:[~2022-05-02 9:51 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 13:10 [v5 00/14] Add support for Bosch BNO055 IMU Andrea Merello
2022-04-26 13:10 ` [v5 01/14] iio: add modifiers for linear acceleration Andrea Merello
2022-04-26 13:10 ` [v5 02/14] iio: document linear acceleration modifiers Andrea Merello
2022-04-26 13:10 ` [v5 03/14] iio: event_monitor: add " Andrea Merello
2022-04-26 13:10 ` [v5 04/14] iio: add modifers for pitch, yaw, roll Andrea Merello
2022-04-26 13:10 ` [v5 05/14] iio: document pitch, yaw, roll modifiers Andrea Merello
2022-04-26 13:10 ` [v5 06/14] iio: event_monitor: add pitch, yaw and " Andrea Merello
2022-04-26 13:10 ` [v5 07/14] iio: add support for binary attributes Andrea Merello
2022-04-26 13:10 ` [v5 08/14] iio: imu: add Bosch Sensortec BNO055 core driver Andrea Merello
2022-04-27 13:22 ` Andy Shevchenko
2022-05-02 9:50 ` Andrea Merello [this message]
2022-05-02 10:11 ` Andy Shevchenko
2022-05-02 13:12 ` Andrea Merello
2022-04-26 13:10 ` [v5 09/14] iio: document bno055 private sysfs attributes Andrea Merello
2022-04-26 13:10 ` [v5 10/14] iio: document "serialnumber" sysfs attribute Andrea Merello
2022-04-26 13:10 ` [v5 11/14] dt-bindings: iio/imu: Add Bosch BNO055 Andrea Merello
2022-04-26 13:11 ` [v5 12/14] iio: imu: add BNO055 serdev driver Andrea Merello
2022-04-27 8:10 ` kernel test robot
2022-04-27 13:41 ` Andy Shevchenko
2022-05-03 7:48 ` Andrea Merello
2022-05-03 13:30 ` Andrea Merello
2022-05-03 14:04 ` Andy Shevchenko
2022-04-27 14:24 ` kernel test robot
2022-04-26 13:11 ` [v5 13/14] iio: imu: add BNO055 I2C driver Andrea Merello
2022-04-26 13:11 ` [v5 14/14] docs: iio: add documentation for BNO055 driver Andrea Merello
2022-04-27 13:42 ` [v5 00/14] Add support for Bosch BNO055 IMU Andy Shevchenko
2022-05-01 17:03 ` Jonathan Cameron
2022-05-02 6:33 ` Andrea Merello
2022-05-02 7:47 ` Andy Shevchenko
2022-05-02 8:31 ` Andrea Merello
2022-05-02 8:52 ` Andy Shevchenko
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=CAN8YU5PzwmeQ9XA3qod7HejG6cCLCrPvda5eomCh5hUze_DWcA@mail.gmail.com \
--to=andrea.merello@gmail.com \
--cc=andrea.merello@iit.it \
--cc=andy.shevchenko@gmail.com \
--cc=ardeleanalex@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=jacopo@jmondi.org \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.ranostay@konsulko.com \
--cc=mchehab+huawei@kernel.org \
--cc=robh+dt@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).