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: <alpine.LFD.2.00.0907221830410.2813@localhost.localdomain>
Date:	Wed, 22 Jul 2009 18:40:21 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Mark Brown <broonie@...nsource.wolfsonmicro.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, 22 Jul 2009, Dmitry Torokhov wrote:
> > 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.
> >  
> 
> I do think this should be set up by the driver - the platform/arch code
> can't be 100% certain what model of servicing interrupts driver will
> chose, nor the driver can know whether arch code set things up for
> threaded or classic interrupt handling.
> 
> Since handle_level_oneshot_irq requires drivers to use threaded IRQ
> model (in absence of thread interrupt will never be unmasked) it would
> be better if we did set it up automatically, right there in
> request_threaded_irq(). This would reduce maintenance issues between
> platform and driver code.

No, it's the wrong way round. 

The platform code sets up the platform devices. So there is no real
good reason that the platform code does not know about the details.

If it conveys the wrong irq number then it wont work, if it sets the
wrong handler it wont work either. So what ?

If the driver is implemented to use a threaded handler, which it
better is no matter what as it uses a bus, and the interrupt
controller logic is proper implemented as well then the driver does
not care about those details at all. It will magically work with any
interrupt controller you put in front of it.

If the platform maintainer sets the wrong handler or the wrong
platform data then it's not the driver writers problem.

Thanks,

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