| Message ID | 1409175484-9145-1-git-send-email-balbi@ti.com |
|---|---|
| State | Accepted |
| Commit | 96908589a8b2584b1185f834d365f5cc360e8226 |
| Headers | show |
On Wed, Aug 27, 2014 at 04:38:04PM -0500, Felipe Balbi wrote: > Commit 71c731a (usb: host: xhci: Fix Compliance Mode > on SN65LVP3502CP Hardware) implemented a workaround > for a known issue with Texas Instruments' USB 3.0 > redriver IC but it left a condition where any xHCI > host would be taken out of reset if port was placed > in compliance mode and there was no device connected > to the port. > > That condition would trigger a fake connection to a > non-existent device so that usbcore would trigger a > warm reset of the port, thus taking the link out of > reset. > > This has the side-effect of preventing any xHCI host > connected to a Linux machine from starting and running > the USB 3.0 Electrical Compliance Suite because the > port will mysteriously taken out of compliance mode > and, thus, xHCI won't step through the necessary > compliance patterns for link validation. > > This patch fixes the issue by just adding a missing > check for XHCI_COMP_MODE_QUIRK inside > xhci_hub_report_usb3_link_state() when PORT_CAS isn't > set. > > This patch should be backported to all kernels containing > commit 71c731a. > > Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) > Cc: Alexis R. Cortes <alexis.cortes@ti.com> > Cc: <stable@vger.kernel.org> # v3.2+ > Signed-off-by: Felipe Balbi <balbi@ti.com> > --- > > This has been tested on a certification setup with LeCroy Voyager M3i > and a really expensive oscilloscope :-) > > Without this patch we cannot keep the host in compliance. > > drivers/usb/host/xhci-hub.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c > index aa79e87..69aece3 100644 > --- a/drivers/usb/host/xhci-hub.c > +++ b/drivers/usb/host/xhci-hub.c > @@ -468,7 +468,8 @@ static void xhci_hub_report_usb2_link_state(u32 *status, u32 status_reg) > } > > /* Updates Link Status for super Speed port */ > -static void xhci_hub_report_usb3_link_state(u32 *status, u32 status_reg) > +static void xhci_hub_report_usb3_link_state(struct xhci_hcd *xhci, > + u32 *status, u32 status_reg) > { > u32 pls = status_reg & PORT_PLS_MASK; > > @@ -507,7 +508,8 @@ static void xhci_hub_report_usb3_link_state(u32 *status, u32 status_reg) > * in which sometimes the port enters compliance mode > * caused by a delay on the host-device negotiation. > */ > - if (pls == USB_SS_PORT_LS_COMP_MOD) > + if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && > + (pls == USB_SS_PORT_LS_COMP_MOD)) > pls |= USB_PORT_STAT_CONNECTION; > } > > @@ -666,7 +668,7 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, > } > /* Update Port Link State */ > if (hcd->speed == HCD_USB3) { > - xhci_hub_report_usb3_link_state(&status, raw_port_status); > + xhci_hub_report_usb3_link_state(xhci, &status, raw_port_status); > /* > * Verify if all USB3 Ports Have entered U0 already. > * Delete Compliance Mode Timer if so. Looks good, Mathias, can I get an ACK so I can queue this up now? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/28/2014 01:07 AM, Greg KH wrote: > On Wed, Aug 27, 2014 at 04:38:04PM -0500, Felipe Balbi wrote: >> Commit 71c731a (usb: host: xhci: Fix Compliance Mode >> on SN65LVP3502CP Hardware) implemented a workaround >> for a known issue with Texas Instruments' USB 3.0 >> redriver IC but it left a condition where any xHCI >> host would be taken out of reset if port was placed >> in compliance mode and there was no device connected >> to the port. >> >> That condition would trigger a fake connection to a >> non-existent device so that usbcore would trigger a >> warm reset of the port, thus taking the link out of >> reset. >> >> This has the side-effect of preventing any xHCI host >> connected to a Linux machine from starting and running >> the USB 3.0 Electrical Compliance Suite because the >> port will mysteriously taken out of compliance mode >> and, thus, xHCI won't step through the necessary >> compliance patterns for link validation. >> >> This patch fixes the issue by just adding a missing >> check for XHCI_COMP_MODE_QUIRK inside >> xhci_hub_report_usb3_link_state() when PORT_CAS isn't >> set. >> >> This patch should be backported to all kernels containing >> commit 71c731a. >> >> Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) >> Cc: Alexis R. Cortes <alexis.cortes@ti.com> >> Cc: <stable@vger.kernel.org> # v3.2+ >> Signed-off-by: Felipe Balbi <balbi@ti.com> >> --- >> >> This has been tested on a certification setup with LeCroy Voyager M3i >> and a really expensive oscilloscope :-) >> >> Without this patch we cannot keep the host in compliance. >> >> drivers/usb/host/xhci-hub.c | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c >> index aa79e87..69aece3 100644 >> --- a/drivers/usb/host/xhci-hub.c >> +++ b/drivers/usb/host/xhci-hub.c >> @@ -468,7 +468,8 @@ static void xhci_hub_report_usb2_link_state(u32 *status, u32 status_reg) >> } >> >> /* Updates Link Status for super Speed port */ >> -static void xhci_hub_report_usb3_link_state(u32 *status, u32 status_reg) >> +static void xhci_hub_report_usb3_link_state(struct xhci_hcd *xhci, >> + u32 *status, u32 status_reg) >> { >> u32 pls = status_reg & PORT_PLS_MASK; >> >> @@ -507,7 +508,8 @@ static void xhci_hub_report_usb3_link_state(u32 *status, u32 status_reg) >> * in which sometimes the port enters compliance mode >> * caused by a delay on the host-device negotiation. >> */ >> - if (pls == USB_SS_PORT_LS_COMP_MOD) >> + if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && >> + (pls == USB_SS_PORT_LS_COMP_MOD)) >> pls |= USB_PORT_STAT_CONNECTION; >> } >> >> @@ -666,7 +668,7 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, >> } >> /* Update Port Link State */ >> if (hcd->speed == HCD_USB3) { >> - xhci_hub_report_usb3_link_state(&status, raw_port_status); >> + xhci_hub_report_usb3_link_state(xhci, &status, raw_port_status); >> /* >> * Verify if all USB3 Ports Have entered U0 already. >> * Delete Compliance Mode Timer if so. > > Looks good, Mathias, can I get an ACK so I can queue this up now? > Somehow I didn't notice this one until now, anyways, Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index aa79e87..69aece3 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -468,7 +468,8 @@ static void xhci_hub_report_usb2_link_state(u32 *status, u32 status_reg) } /* Updates Link Status for super Speed port */ -static void xhci_hub_report_usb3_link_state(u32 *status, u32 status_reg) +static void xhci_hub_report_usb3_link_state(struct xhci_hcd *xhci, + u32 *status, u32 status_reg) { u32 pls = status_reg & PORT_PLS_MASK; @@ -507,7 +508,8 @@ static void xhci_hub_report_usb3_link_state(u32 *status, u32 status_reg) * in which sometimes the port enters compliance mode * caused by a delay on the host-device negotiation. */ - if (pls == USB_SS_PORT_LS_COMP_MOD) + if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && + (pls == USB_SS_PORT_LS_COMP_MOD)) pls |= USB_PORT_STAT_CONNECTION; } @@ -666,7 +668,7 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, } /* Update Port Link State */ if (hcd->speed == HCD_USB3) { - xhci_hub_report_usb3_link_state(&status, raw_port_status); + xhci_hub_report_usb3_link_state(xhci, &status, raw_port_status); /* * Verify if all USB3 Ports Have entered U0 already. * Delete Compliance Mode Timer if so.
Commit 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) implemented a workaround for a known issue with Texas Instruments' USB 3.0 redriver IC but it left a condition where any xHCI host would be taken out of reset if port was placed in compliance mode and there was no device connected to the port. That condition would trigger a fake connection to a non-existent device so that usbcore would trigger a warm reset of the port, thus taking the link out of reset. This has the side-effect of preventing any xHCI host connected to a Linux machine from starting and running the USB 3.0 Electrical Compliance Suite because the port will mysteriously taken out of compliance mode and, thus, xHCI won't step through the necessary compliance patterns for link validation. This patch fixes the issue by just adding a missing check for XHCI_COMP_MODE_QUIRK inside xhci_hub_report_usb3_link_state() when PORT_CAS isn't set. This patch should be backported to all kernels containing commit 71c731a. Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) Cc: Alexis R. Cortes <alexis.cortes@ti.com> Cc: <stable@vger.kernel.org> # v3.2+ Signed-off-by: Felipe Balbi <balbi@ti.com> --- This has been tested on a certification setup with LeCroy Voyager M3i and a really expensive oscilloscope :-) Without this patch we cannot keep the host in compliance. drivers/usb/host/xhci-hub.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)