lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 14 May 2017 16:15:37 +0100
From:   Jonathan Cameron <>
To:     Andy Shevchenko <>,, Hartmut Knaack <>,
        Lars-Peter Clausen <>,
        Peter Meerwald <>,
        Dmitry Torokhov <>,
        Michael Hennerich <>,
        Daniel Baluta <>,
        Alison Schofield <>,
        Florian Vaussard <>,
        "" <>
Subject: Re: [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger

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 <> 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.
>>>>> +#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.

> Eva
>> -- 
>> With Best Regards,
>> Andy Shevchenko
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to
>> More majordomo info at
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to
> More majordomo info at

Powered by blists - more mailing lists