On Thu, May 26, 2011 at 01:48:46PM -0400, Alan Stern wrote: > On Thu, 26 May 2011, Sarah Sharp wrote: > > > > If, as you say, the spurious events are allowed (or at least, not > > > disallowed) by the xHCI spec, then why bother to test an > > > XHCI_SPURIOUS_SUCCESS flag? You might as well assume that any > > > controller can generate these events. > > > > It's a twisted interpretation of the spec that makes this behavior not > > disallowed, so I think it's pretty unlikely that any other xHCI host > > controller will do this. At least, I haven't seen this behavior on any > > of the other host controllers I've tested on. I'd rather have hardware > > developers who are testing new host controllers see the spew of messages > > and realize they're doing something kind of stupid. We can add a new > > quirk for them if they still decide to ship their hardware. > > Do xHCI hardware developers really test their controllers under Linux? > That would be a welcome change from the corporate strategies we've seen > in the past. :-) I am an agent of change. :) I know Fresco Logic, NEC/Rensas, TI, and Synopsis have all run the xHCI drivers on their development hardware because I see their bug patches and questions, although I'm never sure how much they stress test under Linux. I'm trying to get the Intel chipset group to stress test under Linux more, and I think I'm making some headway there. Sarah Sharp -- 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
