On Wed, Apr 1, 2020 at 10:13 AM Sa, Nuno <Nuno.Sa@xxxxxxxxxx> wrote:
>
> > From: Andy Shevchenko <andy.shevchenko@xxxxxxxxx>
> > Sent: Dienstag, 31. März 2020 20:16
> > To: Sa, Nuno <Nuno.Sa@xxxxxxxxxx>
> > Cc: linux-iio <linux-iio@xxxxxxxxxxxxxxx>; devicetree
> > <devicetree@xxxxxxxxxxxxxxx>; Jonathan Cameron <jic23@xxxxxxxxxx>;
> > Hartmut Knaack <knaack.h@xxxxxx>; Lars-Peter Clausen <lars@xxxxxxxxxx>;
> > Peter Meerwald-Stadler <pmeerw@xxxxxxxxxx>; Rob Herring
> > <robh+dt@xxxxxxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>; Ardelean,
> > Alexandru <alexandru.Ardelean@xxxxxxxxxx>; Hennerich, Michael
> > <Michael.Hennerich@xxxxxxxxxx>
> > 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@xxxxxxxxxx> 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
