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

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 1 Apr 2020 13:27:31 +0000
"Sa, Nuno" <Nuno.Sa@analog.com> wrote:

> > From: linux-iio-owner@vger.kernel.org <linux-iio-owner@vger.kernel.org> On
> > Behalf Of Andy Shevchenko
> > Sent: Mittwoch, 1. April 2020 12:23
> > 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 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/.
> >  
> 
> 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