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@xxxxxx>
>> Cc: <stable@xxxxxxxxxxxxxxx> # v3.2+
>> Signed-off-by: Felipe Balbi <balbi@xxxxxx>
>> ---
>>
>> 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@xxxxxxxxxxxxxxx>
--
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
