On Thu, 3 Mar 2011, Mark Lord wrote: > On 11-03-03 03:11 PM, Alan Stern wrote: > > On Thu, 3 Mar 2011, Mark Lord wrote: > > > >> Okay, dug out a UHCI 1.1 spec, and the indication from there > >> is that uhci_irq() can return IRQ_HANDLED in some cases where IRQ_NONE > >> is more appropriate. > > > > What cases are those? > > > >> Also, it is not masking the "Reserved" bits from the status register. > >> Presumably most implementations "read zero" for those bits, > >> but perhaps not all do. > > > > Perhaps not, but I've never come across one that does. This > > essentially amounts to saying that the only reasons a UHCI controller > > generates an interrupt request are the documented ones. > > > > Suppose the driver did mask out the reserved bits and return IRQ_NONE > > when none of the defined bits were set. An implementation that did set > > one of the reserved bits would then create an interrupt storm. > > You mean, like, the "error -71" storms that I *still* get from time > to time, ever since the early 2.6.2x kernels? No, that's not what I mean. I mean like getting a million IRQs in a fraction of a second, causing the IRQ line to be disabled. Those error -71 storms are more or less normal; they happen when a USB transfer can't be completed because the target device has been disconnected or is not responding. The driver usually resubmits the failed transfer, which then fails again in exactly the same way a millisecond later (or less). 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
