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: <20090722133131.GA28355@rakim.wolfsonmicro.main>
Date:	Wed, 22 Jul 2009 14:31:31 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	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>,
	Peter Zijlstra <peterz@...radead.org>,
	Daniel Ribeiro <drwyrm@...il.com>
Subject: Re: Threaded interrupts for synaptic touchscreen in HTC dream

On Wed, Jul 22, 2009 at 02:58:24PM +0200, Thomas Gleixner wrote:
> On Wed, 22 Jul 2009, Mark Brown wrote:
> > On Wed, Jul 22, 2009 at 12:44:01PM +0200, Thomas Gleixner wrote:

> > >    set_irq_handler(irq, handle_level_oneshot_irq);

> > Yeah, I know - the issue I was having was that the use of set_irq_handler()
> > seemed rather rude for driver code.  Grepping around I see that there

> I don't think it belongs into the driver code. It belongs into the
> platform code which sets up the system and knows what's on which
> interrupt line.

Yeah, that is doable - but it'd be good for usability if it could be
handled transparently by the driver.  Even in board code it's fairly
rare to need to explicitly set the handler if you're not actually
implementing an interrupt controller.  Most of the board-specific code
doing this is doing so for a CPLD, FPGA or similar on the board rather
than configuring a preexisting IRQ for use by a leaf device.

Half the trouble is that if you're not implementing interrupt controller
code then calling set_irq_*() is normally a sign that you're doing
something wrong (for example, for set_irq_type() you should be using
flags on request_irq()).

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

Yes, I think that'll be required for users like gpiolib.  If someone's
done something like have a button implemented by attaching switch to a
GPIO input on for something like jack detect on an audio CODEC or a wake
source for a PMIC then we've got generic code that expects to just take
a gpio/irq and interact with it.
--
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/