Re: [PATCH v3 5/6] iio: imu: Add support for adis16475

[Andy Shevchenko <andy.shevchenko@gmail.com>]

On Wed, Apr 1, 2020 at 10:13 AM Sa, Nuno <Nuno.Sa@analog.com> wrote:
>
> > From: Andy Shevchenko <andy.shevchenko@gmail.com>
> > Sent: Dienstag, 31. März 2020 20:16
> > To: Sa, Nuno <Nuno.Sa@analog.com>
> > Cc: linux-iio <linux-iio@vger.kernel.org>; devicetree
> > <devicetree@vger.kernel.org>; Jonathan Cameron <jic23@kernel.org>;
> > Hartmut Knaack <knaack.h@gmx.de>; Lars-Peter Clausen <lars@metafoo.de>;
> > Peter Meerwald-Stadler <pmeerw@pmeerw.net>; Rob Herring
> > <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Ardelean,
> > Alexandru <alexandru.Ardelean@analog.com>; Hennerich, Michael
> > <Michael.Hennerich@analog.com>
> > Subject: Re: [PATCH v3 5/6] iio: imu: Add support for adis16475
> > On Tue, Mar 31, 2020 at 2:49 PM Nuno Sá <nuno.sa@analog.com> wrote:

...

> > > +#include <asm/unaligned.h>

> I thought we wanted alphabetic order...

Yes, but from more generic header groups to less generic. Inside each
group is alphabetical.
asm/ is less generic than linux/.

> > Usually it goes after linux/*

> > > +#include <linux/bitfield.h>
> > > +#include <linux/bitops.h>
> > > +#include <linux/clk.h>
> > > +#include <linux/debugfs.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/device.h>
> >
> > > +#include <linux/kernel.h>
> >
> > What this is for?
> >
> Yeps. Not really needed...

I think you needed it for DIV_ROUND_UP or alike macros. It also has
container_of...

> > > +#include <linux/iio/buffer.h>
> > > +#include <linux/iio/iio.h>
> > > +#include <linux/iio/imu/adis.h>
> > > +#include <linux/iio/sysfs.h>
> > > +#include <linux/iio/trigger_consumer.h>
> > > +#include <linux/irq.h>
> > > +#include <linux/module.h>
> >
> > > +#include <linux/of_device.h>
> >
> > Do you really need this? Perhaps mod_devicetable.h is what you are looking
> > for.
> >
>
> Yes. For ` of_device_get_match_data ``. If changed by `device_get_match_data`, then I guess
> I can drop it..

Probably change to mod_devicetable.h with property.h.

> > > +#include <linux/spi/spi.h>

...

> > > +       for (i = ARRAY_SIZE(adis16475_3db_freqs) - 2; i >= 1; i--) {
> >
> > Why those margins? size-2 and 1 ?
> >
>
> The -2 is needed since index 7 is not valid. The 1 I honestly don't remember why I did it
> like this. Using > 0 is the same and more "common"...

More common is >= 0. That's my question basically.
And if 7 is not valid why to keep it in the array at all?

> > > +               if (adis16475_3db_freqs[i] >= filter)
> > > +                       break;
> > > +       }

...

> > > +#define ADIS16475_GYRO_CHANNEL(_mod) \
> > > +       ADIS16475_MOD_CHAN(IIO_ANGL_VEL, IIO_MOD_ ## _mod, \
> > > +       ADIS16475_REG_ ## _mod ## _GYRO_L, ADIS16475_SCAN_GYRO_ ##
> > _mod, 32, \
> > > +       32)
> >
> > It's not obvious that this is macro inside macro. Can you indent better?
> > Ditto for the rest similar ones.
> >
>
> Honestly here I don't see any problems with indentation and it goes in conformity with
> other IMU drivers already in tree. So here, as long as anyone else has a problem with this, I prefer
> to keep it this way...

I'm not a maintainer, not my call :-)

...

> > > +       buffer = (u16 *)adis->buffer;
> >
> > Why the casting is needed?
> >
> > > +       crc = get_unaligned_be16(&buffer[offset + 2]);
> >
> > If your buffer is aligned in the structure, you may simple use be16_to_cpu().
> > Same for the rest of get_unaligned*() calls.
> > Or do you have unaligned data there?
>
> This is a nice point. So, honestly I made it like this to keep conformity with other drivers we have
> in our internal tree (in queue for upstream) and I also wondered about this. The only justification I can
> find to use unligned calls is to keep this independent from the ADIS lib (not sure if it makes sense) since
> we get the pointer from the library (allocated there).
>
> Now, if Im not missing nothing obvious we can access the buffer normally since it's being allocated
> with kmalloc which means we have  ARCH_KMALLOC_MINALIGN (which is at least 8 if Im not mistaken).
> On top of this, the device sends the data as n 16 bits segments. So in theory, I guess we can ditch the
> overhead of the *unaligned calls if any objections?

No objections from my side at least.

...

> > > +       desc = irq_get_irq_data(spi->irq);
> >
> > > +       if (!desc) {
> > > +               dev_err(&spi->dev, "Could not find IRQ %d\n", spi->irq);
> > > +               return -EINVAL;
> > > +       }
> >
> > Is this even possible?

> I guess. If someone does not include it in device tree...

Hmm... and this function will be called anyway?

-- 
With Best Regards,
Andy Shevchenko