On Fri, 8 Apr 2011, Kristen Carlson Accardi wrote: > > Perhaps the existing irq and threaded_irq can even be the _same_. > > After all, they need to do pretty much the same things. > > > > Alan Stern > > It worked for me to use the existing usb_hcd_irq as a threadfn, > however with the quickcheck handler the way it is written now, > you'd need to add the intr_enable to the end of usb_hcd_irq, Right, except that the interrupt-enable can't be added to usb_hcd_irq() since that routine is part of the generic "glue" layer. It would have to be added to the end of ehci_irq(). > and > since it never masks the interrupts in the first place I'm not > sure if that would cause any side effects. One would need to carefully keep track of which interrupts are supposed to be enabled at any given time. That shouldn't be hard to do in ehci-hcd, but familiarity with the driver will help a lot -- I'm probably better qualified than you in this regard. > It is also probably > true that we might have different locking requirements for a > threadfn vs. a regular irq. I don't think so. ehci-hcd uses only one spinlock for everything, and since the lock can be acquired while running in a non-threaded interrupt context, there's no choice but to disable interrupts while acquiring it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
