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-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
