All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Dan Robertson <dan@dlrobertson.com>,
	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: Sun, 15 Dec 2019 16:31:03 +0000	[thread overview]
Message-ID: <20191215163103.17cee7d4@archlinux> (raw)
In-Reply-To: <CAHp75VezHcGwwWZ8tSf6FKoYQ_c4=WhYE2ag6OtcAJ2Z9M3ZOA@mail.gmail.com>

On Thu, 12 Dec 2019 11:41:45 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Thu, Dec 12, 2019 at 2:33 AM Dan Robertson <dan@dlrobertson.com> wrote:
> > 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:  
> 
> > > > +#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?  
> 
> SHIFTs -> plain decimals
> 
> > > > +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.  
> 
> I think there might be better way to do this.
> But I leave it to you and maintainer to agree on (I will be fine with
> any solution you will come to).

This does always feel a bit silly.  We have plenty of cases of both
the suggested options (replicate vs export). I don't really care either way.


> 
> > > > +               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.  
> 
> The main point here to get rid of divisions. Is it achievable?
> 
> > > > +                       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  
> 
> There is no positive codes mentioned at all. And you assume right.
> But why we care about positive codes if they never can be returned?
Agreed, for regmap calls, definitely prefer the driver to check with
if (ret)
	...
> 


  reply	other threads:[~2019-12-15 16:31 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
2019-12-12  9:41       ` Andy Shevchenko
2019-12-15 16:31         ` Jonathan Cameron [this message]
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=20191215163103.17cee7d4@archlinux \
    --to=jic23@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=dan@dlrobertson.com \
    --cc=devicetree@vger.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.