linux-kernel - Re: Moving staging:iio over to threaded 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]

Message-ID: <4D762065.7030009@cam.ac.uk>
Date:	Tue, 08 Mar 2011 12:26:13 +0000
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	LKML <linux-kernel@...r.kernel.org>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>
Subject: Re: Moving staging:iio over to threaded interrupts.

On 03/08/11 12:12, Thomas Gleixner wrote:
> On Tue, 8 Mar 2011, Jonathan Cameron wrote:
>> On 03/08/11 10:30, Thomas Gleixner wrote:
>>> So now you can request the interrupts for your subdevices with
>>> request_irq or request_threaded_irq.
>>>
>>> You can also implement #1 this way, you just mark the sub device
>>> interrupts as IRQ_NESTED_THREAD, and then call the handlers from the
>>> main trigger irq thread.
>> Hi Thomas,
>>
>> One issue here that I'm not quite sure how to overcome is that the trigger to
>> device mapping tends to be dynamic.  That is we quite often switch around
>> what device is triggered by which trigger at runtime.  All done via text label
>> matching via sysfs.
> 
> Was not aware of that.
>  
>> I guess we could maintain this by a spot of indirection and pool of interrupts per
>> trigger (with compile time control on how many). Any other approaches come to mind?
> 
> That should work. You just need a function in the trigger
> implementation which hands back an unused irq number to the device
> when a trigger is installed for a device. Then the device calls
> request[_threaded]_irq() on that irq number and all should work
> magically.
> 
Cool.  Actually thinking more on this we probably want to have a single pool for IIO
in general that then allocates sets to the individual drivers.  That way things
like dynamic trigger creation (which is needed for the bridge to the input subsystem
but not currently implemented) become possible.

Thanks for the quick reply!

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/