All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Robertson <dan@dlrobertson.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	linux-iio <linux-iio@vger.kernel.org>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	devicetree <devicetree@vger.kernel.org>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Joe Perches <joe@perches.com>
Subject: Re: [PATCH v6 2/2] iio: (bma400) add driver for the BMA400
Date: Thu, 12 Dec 2019 00:17:35 +0000	[thread overview]
Message-ID: <20191212001735.GA4667@nessie> (raw)
In-Reply-To: <CAHp75VdAJwMkPZQLLQrOk4HABjG-parEOmH8S-6kU+zyYnnfww@mail.gmail.com>

On Wed, Dec 11, 2019 at 03:21:56PM +0200, Andy Shevchenko wrote:
> On Wed, Dec 11, 2019 at 3:20 AM Dan Robertson <dan@dlrobertson.com> wrote:
> >
> > Add a IIO driver for the Bosch BMA400 3-axes ultra-low power accelerometer.
> > The driver supports reading from the acceleration and temperature
> > registers. The driver also supports reading and configuring the output data
> > rate, oversampling ratio, and scale.
> 
> > +#define BMA400_LP_OSR_SHIFT         0x05
> > +#define BMA400_NP_OSR_SHIFT         0x04
> > +#define BMA400_SCALE_SHIFT          0x06
> 
> I'm not sure why this is being defined as hex number instead of plain decimal...

Sounds good.

> > +#define BMA400_TWO_BITS_MASK        GENMASK(1, 0)
> > +#define BMA400_LP_OSR_MASK          GENMASK(6, BMA400_LP_OSR_SHIFT)
> > +#define BMA400_NP_OSR_MASK          GENMASK(5, BMA400_NP_OSR_SHIFT)
> > +#define BMA400_ACC_ODR_MASK         GENMASK(3, 0)
> > +#define BMA400_ACC_SCALE_MASK       GENMASK(7, BMA400_SCALE_SHIFT)
> 
> And here simple better to put same numbers. It will help to read.

Do you mean for the shift or for the mask?

> > +const struct regmap_config bma400_regmap_config = {
> > +       .reg_bits = 8,
> > +       .val_bits = 8,
> > +       .max_register = BMA400_CMD_REG,
> > +       .cache_type = REGCACHE_RBTREE,
> > +       .writeable_reg = bma400_is_writable_reg,
> > +       .volatile_reg = bma400_is_volatile_reg,
> > +};
> > +EXPORT_SYMBOL(bma400_regmap_config);
> 
> I'm not sure I got the idea why this one is being exported.

It needs to be exported so that it can be used in the bma400_i2c module and the
future bma400_spi module. In theory, if we _really_ do not want to export this,
then we can define separate regmap configs in each of the bma400_i2c and
(future) bma400_spi modules, but then we would have to export the is_volitile_reg
and is_writable_reg functions. As a result, I do not see any benefits to that
method over exporting the config, but I could be convinced otherwise.

> > +               if (odr < BMA400_ACC_ODR_MIN_RAW ||
> > +                   odr > BMA400_ACC_ODR_MAX_RAW) {
> 
> One line?

It is too long if I simplify to one line.

> > +               if (uhz || hz % BMA400_ACC_ODR_MIN_WHOLE_HZ)
> > +                       return -EINVAL;
> > +
> > +               val = hz / BMA400_ACC_ODR_MIN_WHOLE_HZ;
> > +               idx = __ffs(val);
> > +
> 
> > +               if (val ^ BIT(idx))
> 
> Seems like funny way of checking is_power_of_2(). But it's up to maintainers.
> And your variant may even be better here (in code generation perspective)...
> 
> However, the whole idea here is, IIUC, to have something like
> 
>   hz = 2^idx * BMA400_ACC_ODR_MIN_WHOLE_HZ
> 
> I think you may do it without divisions, i.e. call __ffs() first and then do
>    idx = __ffs(...);
>    val = hz >> idx;
>    if (val != BMA400_ACC_ODR_MIN_WHOLE_HZ)
>     return -EINVAL;
> 
> or something like above.

It would be more obvious what is being done here with is_power_of_two. I'll
revisit this function with your suggestions. If I can make it simpler, I'll
go this route.

> 
> > +                       return -EINVAL;
> 
> ...
> 
> > +       odr = (~BMA400_ACC_ODR_MASK & val) | idx;
> 
> I'm wondering why Yoda style is being used here.

I guess I think like Yoda :) I can update this. I typically do prefer
new_mask | old_mask, but I do not feel too strongly about it.

> > +static void bma400_accel_scale_from_raw(int raw, unsigned int *val)
> > +{
> > +       *val = BMA400_SCALE_MIN * (1 << raw);
> 
> Isn't it the same as
>     *val = BMA400_SCALE_MIN << raw;
> ?

Yes. Good catch. Not sure what I was thinking :)

> 
> > +               return -EINVAL;
> 
> ...
> 
> > +       ret = regmap_read(data->regmap, BMA400_ACC_CONFIG0_REG, &val);
> > +       if (ret < 0)
> 
> I'm wondering if in all of these regmap_read()...
> 
> > +               return ret;
> 
> > +       ret = regmap_write(data->regmap, BMA400_ACC_CONFIG0_REG,
> > +                          mode | (val & ~BMA400_TWO_BITS_MASK));
> > +       if (ret < 0) {
> 
> ...and regmap_write() calls you ever can get a positive returned code.

From the regmap_read/regmap_write docs:

> * A value of zero will be returned on success, a negative errno will
> * be returned in error cases.

So I assume ret <= 0

Cheers,

 - Dan


  reply	other threads:[~2019-12-12  0:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11  1:03 [PATCH v6 0/2] iio: add driver for Bosch BMA400 accelerometer Dan Robertson
2019-12-11  1:03 ` [PATCH v6 1/2] dt-bindings: iio: accel: bma400: add bindings Dan Robertson
2019-12-12 10:16   ` Linus Walleij
2019-12-18 17:05     ` Rob Herring
2019-12-18 21:16       ` Dan Robertson
2019-12-18 17:20   ` Rob Herring
2019-12-11  1:03 ` [PATCH v6 2/2] iio: (bma400) add driver for the BMA400 Dan Robertson
2019-12-11 13:21   ` Andy Shevchenko
2019-12-12  0:17     ` Dan Robertson [this message]
2019-12-12  9:41       ` Andy Shevchenko
2019-12-15 16:31         ` Jonathan Cameron
2019-12-12 10:27   ` Linus Walleij

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=20191212001735.GA4667@nessie \
    --to=dan@dlrobertson.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=joe@perches.com \
    --cc=knaack.h@gmx.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pmeerw@pmeerw.net \
    --cc=rdunlap@infradead.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 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.