linux-kernel - Re: [PATCH 3/3] iio: st_sensors: Use level interrupts

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:	Sun, 29 May 2016 20:29:40 +0100
From:	Jonathan Cameron <jic23@...nel.org>
To:	Crestez Dan Leonard <leonard.crestez@...el.com>,
	Linus Walleij <linus.walleij@...aro.org>
Cc:	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Hartmut Knaack <knaack.h@....de>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Peter Meerwald-Stadler <pmeerw@...erw.net>,
	Daniel Baluta <daniel.baluta@...el.com>,
	Giuseppe Barba <giuseppe.barba@...com>,
	Denis Ciocca <denis.ciocca@...com>
Subject: Re: [PATCH 3/3] iio: st_sensors: Use level interrupts

On 24/05/16 13:35, Crestez Dan Leonard wrote:
> On 05/24/2016 02:40 PM, Linus Walleij wrote:
>> On Fri, May 13, 2016 at 8:43 PM, Crestez Dan Leonard
>> <leonard.crestez@...el.com> wrote:
>>
>>> As far as I can tell DRDY for ST sensors behaves as a level rather than
>>> edge interrupt. Registering for IRQF_TRIGGER_RISING instead of
>>> IRQF_TRIGGER_HIGH mostly works except when the sampling frequency is
>>> high enough that new samples come before the new ones are read
>>> completely. In that case the interrupt line remains high, no more rising
>>> edges occur and the iio buffer stalls.
>>>
>>> Configuring the interrupt as IRQF_TRIGGER_HIGH makes it work as
>>> expected. This patch makes it so that st_sensors_trigger interrupt
>>> request code doesn't mangle the request flags into IRQF_TRIGGER_RISING.
>>>
>>> Cc: Linus Walleij <linus.walleij@...aro.org>
>>> Cc: Giuseppe Barba <giuseppe.barba@...com>
>>> Cc: Denis Ciocca <denis.ciocca@...com>
>>> Signed-off-by: Crestez Dan Leonard <leonard.crestez@...el.com>
>>
>> The analysis is probably correct: the sensors will hold the line low
>> until the values have been read and no data is ready in the pipe.
>>
>> This is delicate when the sensors are used with GPIO controllers
>> as interrupt line handlers, because some of them (like mine
>> on Ux500) do not support level interrupts :(
> 
> This might be completely crazy, but wouldn't it be possible to support
> gpio level interrupts purely in software? Just read the GPIO state again
> after the interrupt is unmasked and retrigger.
> 
> This seems preferable to implementing per-driver workarounds. Perhaps it
> would even fit in some gpio-irqchip glue.
That's precisely the question I raised way back when writing the lis3l02dq
driver.  Apparently someone once had a go but it never went anywhere...

Feel free to try! It would be great if possible.

Jonathan
>