Re: [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger

[Jonathan Cameron]

On 10/05/17 14:24, Eva Rachel Retuya wrote:
> On Wed, May 03, 2017 at 12:05:00AM +0300, Andy Shevchenko wrote:
> > On Tue, May 2, 2017 at 3:15 PM, Eva Rachel Retuya <eraretuya@xxxxxxxxx> wrote:
> > > On Mon, May 01, 2017 at 02:31:00PM +0300, Andy Shevchenko wrote:
> > > [...]
> > > > > -int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> > > > > +int adxl345_core_probe(struct device *dev, struct regmap *regmap, int irq,
> > > > >                         const char *name);
> > > >
> > > > I think I commented this once. Instead of increasing parameters,
> > > > please introduce a new struct (as separate preparatory patch) which
> > > > will hold current parameters. Let's call it
> > > > strut adxl345_chip {
> > > >   struct device *dev;
> > > >   struct regmap *regmap;
> > > >   const char *name;
> > > > };
> > > >
> > > > I insisnt in this chage.
> > >
> > > I'm not sure if what you want is more simpler, is it something like what
> > > this driver does?
> >
> > Nope. The driver you were referring to does the same you did.
> >
> > I'm proposing the above struct to be introduced along with changing
> > prototype like:
> >
> >   -int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> > const char *name);
> >   +int adxl345_core_probe(struct adxl345_chip *chip);
> >
> > In next patch adding interrupt would not touch prototypes at all!
>
> OK, got it. Thanks for clarifying.
>
> > > http://lxr.free-electrons.com/source/drivers/iio/gyro/mpu3050.h#L41
> > > http://lxr.free-electrons.com/source/drivers/iio/gyro/mpu3050-i2c.c#L34
> >
> > > > > +#include <linux/of_irq.h>
> > > >
> > > > Can we get rid of gnostic resource providers?
> > >
> > > I'm uninformed and still learning. Please let me know how to approach
> > > this in some other way.
> >
> > I suppose something like platform_get_irq(); to use.
> > But it would be nice to you to investigate more.
>
> I had a look and it seems I have to convert to platform_driver in order
> to make use of that function. Is this correct?
I believe Andy was suggesting a function 'similar to' that one rather
than actually using platform_get_irq.

It's not an area I know all that much about either, but there
are moves to try and move the boiler plat needed to get the same
parameters from devicetree and acpi into core library code so
that a single function can be called to get the parameter in
either case.

Jonathan
> Eva
>
> > --
> > With Best Regards,
> > Andy Shevchenko
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html