On Wed, 14 Nov 2012, Alan Stern wrote: > On Tue, 13 Nov 2012 gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > From e592c5d0b7db94b485b4a2342db041a1882b7f75 Mon Sep 17 00:00:00 2001 > > From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > Date: Tue, 13 Nov 2012 10:52:52 -0800 > > Subject: Revert "USB/host: Cleanup unneccessary irq disable code" > > > > This reverts commit 73d4066055e0e2830533041f4b91df8e6e5976ff. > > > > Martin Steigerwald reported that this change caused a hard lockup when > > using USB if threadirqs are enabled. Thomas pointed out that this patch > > is incorrect, and can cause problems. So revert it to get the > > previously working functionality back. > > This reminds me -- it might be a good idea to start migrating the USB > host controller drivers to use threaded interrupts. The difficulty is > that I'm not sure what would be required. I had some rough go at it two years ago, but hell don't ask me where I buried those patches. The main thing is that you need a real primary handler, which runs in hard interrupt context, because the USB interrupts are often shared and you don't want and cannot block out the other devices while you are handling your device. So the primary handler has to figure out (as it does now) whether the interrupt originates from the USB device. If not it returns IRQ_NONE as now. If yes, it has to disable the interrupt at the host device level and return IRQ_WAKE_THREAD. IIRC one of the problems I ran into was that not all host controllers preserve the interrupt cause when you have read it out already, but my memory is really blurry. Now the threaded handler does the device handling and at the end of it, it reenables the interrupts at the device level again for the next round. So the only thing you have to worry about vs. interupts is protecting the access to the irq related hardware registers and of course vs. the timers. Btw, what's the reason for using hrtimers in USB? Thanks, tglx -- 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
