Hello Andy, On Mon, Mar 21, 2022 at 10:39:22AM +0200, Andy Shevchenko wrote: > On Sat, Mar 19, 2022 at 8:10 PM Jagath Jog J <jagathjog1996@xxxxxxxxx> wrote: > > > > Added trigger buffer support to read continuous acceleration > > data from device with data ready interrupt which is mapped > > to INT1 pin. > > ... > > > #include <linux/mutex.h> > > #include <linux/regmap.h> > > #include <linux/regulator/consumer.h> > > +#include <linux/bits.h> > > +#include <linux/bitfield.h> > > It would be nice to keep the above in order. > > > +#include <linux/iio/buffer.h> > > +#include <linux/iio/trigger.h> > > +#include <linux/iio/triggered_buffer.h> > > +#include <linux/iio/trigger_consumer.h> > > These ones, possibly including iio headers from the above piece, are > good to be grouped together here with a blank line in between the > above part and iio/*. > > ... > > > +static const unsigned long bma400_avail_scan_masks[] = { > > + GENMASK(3, 0), > > > + 0, > > No need to have a comma in terminator entry. > > > +}; > > ... > > > + ret = regmap_bulk_read(data->regmap, BMA400_X_AXIS_LSB_REG, > > + &data->buffer.buff, 3 * sizeof(__be16)); > > sizeof(buff) > > ... > > > +out: Just to skip the below "if()" if error occurs in previous regmap read, I used this label. if (status & BMA400_INT_DRDY_MSK) iio_trigger_poll_chained(data->trig); I will remove the label in next patch > > A useless label. Moreover this raises a question: why is it okay to > always mark IRQ as handled? > > > + return IRQ_HANDLED; Since I was not using top-half of the interrupt so I marked IRQ as handled even for error case in the handler. > > ... > > > + dev_err(dev, "iio trigger register failed\n"); > > + return ret; > > return dev_err_probe(); > > ... > > > + dev_err(dev, "request irq %d failed\n", irq); > > + return ret; > > Ditto. > > ... > > > + dev_err(dev, "iio triggered buffer setup failed\n"); > > + return ret; > > Ditto. I will change this in the next patch version. > > -- > With Best Regards, > Andy Shevchenko