Hi, On Wed, Jun 26, 2013 at 05:46:29PM +0530, George Cherian wrote: > >>@@ -25,6 +25,16 @@ static void xhci_plat_quirks(struct device *dev, struct > >>xhci_hcd *xhci) > >> * dev struct in order to setup MSI > >> */ > >> xhci->quirks |= XHCI_BROKEN_MSI; > >>+ > >>+ /* > >>+ * In some xhci controllers which follows xhci 1.0 spec gives a spurious > >>+ * success event after a short transfer. This quirk will ignore such > >>+ * spurious event. Hit this issue in synopsis xhci controllers with > >>+ * hci_version > 0.96 > >>+ */ > >>+ > >>+ if (xhci->hci_version > 0x96) > >>+ xhci->quirks |= XHCI_SPURIOUS_SUCCESS; > >> } > >doesn't look like the correct way to do this. What if enabling that > >quirk on hosts which don't have the quirk cause problems ? > For a controller which does not have this issue will never get a > spurious success for short packet ( and that too for only ISOCH). > > per this commit ad808333d Intel xhci: Ignore spurious successful event. > > This spurious successful event behavior isn't technically disallowed by > the xHCI specification, so make the xHCI driver just ignore the spurious > completion event.
still we don't want to enable quirks for devices which aren't quirky :-) Now how Sarah correctly enables the quirk flag only for the known "bad" Panther Point device. > >I would suggest adding a platform_data which (in our case) dwc3 will > >pass to xhci-plat. Then you can do proper revision detection of the > >synopsys controller and set the quirk only on the failing hosts. > > > >BTW, do you have the STARS number for this errata ? > No STARS number yet. once we have it, let's make sure to follow what we do on the dwc3 and list it in a comment. You already that you found the bug with a Synopsys controller anyway, might as well point to the fact that there is a ticket with synopsys to track this issue. cheers -- balbi
signature.asc
Description: Digital signature
