> From: linux-iio-owner@xxxxxxxxxxxxxxx <linux-iio-owner@xxxxxxxxxxxxxxx> On
> Behalf Of Andy Shevchenko
> Sent: Mittwoch, 1. April 2020 12:23
> 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 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/.
>
Got it...
> > > 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...
>
Yes, DIV_ROUND_CLOSEST is defined there...
> > > > +#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?
Well, I can remove the 7. I honestly took it from another driver and I guess the idea
is to make explicit that 7 is not supported. Since this is a 3 bit field and the datasheet
does not state this directly.
As for the >=0, I prefer to have either as is or >0 since we don't really need to check the
index 0. If 1 fails, then we will use 0 either way...
> > > > + 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.
>
I will wait to see if someone else has anything to add and if not, I will change it
to normal buffer accesses (probably using restricted types).
> ...
>
> > > > + 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?
>
Yes, it is called on probe... And we should fail if no interrupt is given
in device tree. It’s a required property.
- Nuno Sá
> --
> With Best Regards,
> Andy Shevchenko
