lists.openwall.net   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  linux-cve-announce  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:   Thu, 17 Aug 2017 07:55:45 -0400
From:   Harinath Nampally <harinath922@...il.com>
To:     Martin Kepplinger <martink@...teo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>
Cc:     jic23@...nel.org, knaack.h@....de, lars@...afoo.de,
        gregkh@...uxfoundation.org, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org, amsfield22@...il.com
Subject: Re: [PATCH] iio: accel: mma8452: Bugfix to enbale and allow different
 events to work parallely.

> This patch fixes by detaching the event related information from
> chip_info struct,
>>> and based on channel type and event direction the corresponding
> event configuration registers
>>> are picked dynamically. Hence multiple events can be handled in
> read/write callbacks.
>> which chip can have which event(s)?
> I am planning to add 'supported events' field in
>
> struct mma_chip_info which indicates which chip can have which events.
> During initialization in 'mma_chip_info_table' would set this
> 'supported events' field for each chip.
> But I wonder should I add those changes as part of this patch?
> is it necessary or can it be documentation?
I think its not necessary as we only have Freefall and Transient events 
for now.
Ok I will just update the documentation.
>
> And this patch should have been called "v2". please include a persistent version history to v3 of this patch.
Sure I will send v3 patch, should I use '--in-reply-to' option of git 
send-email to send v3 patch as reply to
original thread?

On 08/17/2017 07:24 AM, Martin Kepplinger wrote:
>>>> This patch fixes by detaching the event related information from
>> chip_info struct,
>>>> and based on channel type and event direction the corresponding
>> event configuration registers
>>>> are picked dynamically. Hence multiple events can be handled in
>> read/write callbacks.
>>> which chip can have which event(s)?
>> I am planning to add 'supported events' field in
>>
>> struct mma_chip_info which indicates which chip can have which events.
>> During initialization in 'mma_chip_info_table' would set this
>> 'supported events' field for each chip.
>> But I wonder should I add those changes as part of this patch?
> is it necessary or can it be documentation?
>
> And this patch should have been called "v2". please include a persistent version history to v3 of this patch.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ