Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 20 Dec 2019 15:28:05 +0000
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>,
        Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH v7 2/3] iio: (bma400) add driver for the BMA400
Message-ID: <20191220152805.GD16415@nessie>
References: <20191219041039.23396-1-dan@dlrobertson.com>
 <20191219041039.23396-3-dan@dlrobertson.com>
 <CAHp75VdVmfAi5hSp23Gn8nm6LmX-Mr5Tnxcbus90DrRL+gVFRA@mail.gmail.com>
 <20191220043220.GA16415@nessie>
 <CAHp75Vec5ADoFH9KoTnU5+uEZvGqS2+NUN+MLTiwzofDtGG0+A@mail.gmail.com>
 <CAHp75VdzE4uKKJ_5g8eMZR+GSX9W+7Lc+kh2OYt5o7_8_NHTpw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHp75VdzE4uKKJ_5g8eMZR+GSX9W+7Lc+kh2OYt5o7_8_NHTpw@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Dec 20, 2019 at 11:32:42AM +0200, Andy Shevchenko wrote:
> On Fri, Dec 20, 2019 at 11:27 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Fri, Dec 20, 2019 at 6:48 AM Dan Robertson <dan@dlrobertson.com> wrote:
> > > On Thu, Dec 19, 2019 at 01:02:28PM +0200, Andy Shevchenko wrote:
> > > > On Thu, Dec 19, 2019 at 6:27 AM Dan Robertson <dan@dlrobertson.com> wrote:
> >
> > > > > +static int bma400_set_accel_output_data_rate(struct bma400_data *data,
> > > > > +                                            int hz, int uhz)
> > > > > +{
> > > > > +       unsigned int idx;
> > > > > +       unsigned int odr;
> > > > > +       unsigned int val;
> > > > > +       int ret;
> > > > > +
> > > > > +       if (hz >= BMA400_ACC_ODR_MIN_WHOLE_HZ) {
> > > > > +               if (uhz || hz % BMA400_ACC_ODR_MIN_WHOLE_HZ)
> > > > > +                       return -EINVAL;
> > > > > +
> > > > > +               val = hz / BMA400_ACC_ODR_MIN_WHOLE_HZ;
> > > >
> > > > Again, AFAICS division may be avoided in both cases (% and / above)
> > > > because of is_power_of_2() check below.
> > > > Can you revisit this?
> > >
> > > Yeah I can update this in the next patchset, but I don't know if it is much more
> > > readable this way.
> >
> > You may describe the algo in the comment.
> >
> > Let's see how it might look like
> >
> >   if (uhz)
> >     return -EINVAL;
> >   idx = __ffs(val);
> >   /* We're expecting value to be 2^n * ODR_MIN_WHOLE_HZ */
> >   if ((val >> idx) != BMA400_ACC_ODR_MIN_WHOLE_HZ)
> 
> Okay, this would require trickier conditional for the cases when
> MIN_WHOLE_HZ can be divided by 2^k...
> Still from performance point of view it might be much faster than division.

I think the other checks will ensure we return -EINVAL in those cases. I ran a
basic for loop and verified this.

Cheers,

 - Dan