linux-kernel - Re: Threaded interrupts for synaptic touchscreen in HTC dream

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: <1248269443.27058.1449.camel@twins>
Date:	Wed, 22 Jul 2009 15:30:43 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Trilok Soni <soni.trilok@...il.com>,
	Pavel Machek <pavel@....cz>, Arve Hj?nnev?g <arve@...roid.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	Brian Swetland <swetland@...gle.com>,
	linux-input@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	linux-i2c@...r.kernel.org,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	m.szyprowski@...sung.com, t.fujak@...sung.com,
	kyungmin.park@...sung.com, David Brownell <david-b@...bell.net>,
	Daniel Ribeiro <drwyrm@...il.com>
Subject: Re: Threaded interrupts for synaptic touchscreen in HTC dream

On Wed, 2009-07-22 at 14:58 +0200, Thomas Gleixner wrote:
>  One
> thing which I definitely want to change is the thread_eoi function. We
> probably want to have it customizable for the following reason:
> 
> main interrupt
>      hardirq handler wakes main thread handler
> 
> main thread handler
>     bus magic
>    	subdevice1 "hardirq" handler wakes subdevice1 irq thread
>    	subdevice2 "hardirq" handler wakes subdevice2 irq thread
>     main thread handler waits for subdevice1/2 handlers to complete
> 
> subdevice1 thread handler
>     bus magic
>     ....
>     thread_fn returns
>     signal main thread handler via completion
> 
> subdevice2 thread handler
>     bus magic
>     ....
>     thread_fn returns
>     signal main thread handler via completion
> 
> main thread handler resumes
>     bus magic
>     main thread handler returns from thread_fn
>     unmask main interrupt
> 
> So the thread_eoi function is useful for both the main and the
> subdevice handlers. The main handler probably just issues the unmask
> while the subdevice handlers probably want to call a completion to
> notify the main thread handler that they are done. That would be a
> fairly proper design I think and would encourage driver writers to
> follow the common scheme instead of doing their own black magic.
> 
> Thinking further we should even provide some infrastructure for that
> in the common code which would handle the completion and attach it to
> the interrupts in question, so the driver authors would not have to
> deal with that at all. They just would return from thread_fn and let
> the generic code deal with the notification. The notification has to
> be set up by the interrupt controller code. That way you can use the
> same device driver code w/o knowledge of the interrupt controller
> implementation it is attached to.

Wouldn't it be better if we could express the nesting property from
within genirq, so that we can do things like:

  register_chip_nested(parent_chip, parent_irq, slave_chip);

And let genirq set-up the needed magic to make the nesting work.


Also, how important is it that subhandler1..n run in their own thread?
That is, can't we let them run from the thread that is otherwise waiting
for the completino anyway?


--
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/