Hi Thomas,

On Wed, Jul 22, 2009 at 02:58:24PM +0200, Thomas Gleixner wrote:

Mark,

On Wed, 22 Jul 2009, Mark Brown wrote:

quoted

On Wed, Jul 22, 2009 at 12:44:01PM +0200, Thomas Gleixner wrote:

quoted

On Tue, 21 Jul 2009, Mark Brown wrote:

quoted

quoted

I'll need to have a more detailed look at that but it's not immediately
clear to me how a driver (or even machine) should use that code - it
looks more like it's intended to be called from within the IRQ
infrastructure than from random driver code.

quoted

All it needs is to set handle_level_oneshot_irq for the interrupt line
of your I2C or whatever devices. 

quoted

   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
are actually a small number of drivers using it already but at first
glance most of them appear to be implementing interrupt controllers.  It
was setting off alarm bells about abstraction layer violation like
set_irq_type() does.

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.

Thanks.

-- 
Dmitry