On Wed, 1 Apr 2020 13:27:31 +0000
"Sa, Nuno" <Nuno.Sa@xxxxxxxxxx> wrote:
> > 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).
It would be very odd to get a buffer from a library dealing with this sort of
device that wanted at least 8 byte aligned. I guess we could add a paranoid
check in the driver, but I think we can safely assume this is fine without one.
> > >
> > > 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).
>
If it's aligned, definitely prefer that to be explicit in the driver and use
the relevant endian types.
We have had a few cases where things are oddly padded so this may be cut and
paste from one of those.
Jonathan
