Hi Thomas, On Wed, Jul 22, 2009 at 02:58:24PM +0200, Thomas Gleixner wrote: > Mark, > > On Wed, 22 Jul 2009, Mark Brown wrote: > > > On Wed, Jul 22, 2009 at 12:44:01PM +0200, Thomas Gleixner wrote: > > > On Tue, 21 Jul 2009, Mark Brown wrote: > > > > > > 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. > > > > > All it needs is to set handle_level_oneshot_irq for the interrupt line > > > of your I2C or whatever devices. > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
