On Tue, Jul 10, 2012 at 05:32:35PM -0500, Alexis Cortes wrote:
> Hi Sarah & Greg,
>
> I made another patch for this issue following your recommendations. The only
> thing that is left is the way the patch is going to be implemented on the
> kernel (module parameter, sysfs...), which is still in discussion. The
> changes I made for this patch are as follows:
>
> * Changed #define COMP_MODE_RCVRY_TIMEOUT 2 by #define COMP_MODE_RCVRY_MSECS
> 2000.
> * Timer implemented as a Slack Timer.
> * Stop and Restart the timer when the host is suspended.
> * Let the USB core handle the warm reset.
> * Stop timer when all ports have entered U0.
That's a much nicer version, thanks.
Few minor corrections below:
> [PATCH] usb: host: xhci: Compliance Mode Port Recovery
Better subject: "Fix compliance mode on SN65LVPE502CP hardware"?
As this is a fix for broken hardware, right?
> + } else {
> + /* If CAS bit isn't set but the Port is already at
> + * Compliance Mode, fake a connection so the USB core
> + * notices the Compliance state and resets the port
Add "This resolves an issue with the..." describing the hardware
problem?
> + xhci_dbg(xhci, "Compliance Mode
> Recovery Timer "
> + "Deleted. All USB3
> ports have "
> + "entered U0 at least
> once.\n");
Keep the string all on one line.
> +/*Compliance Mode Recovery Patch*/
Why is this comment needed?
> +static void compliance_mode_rcvry(unsigned long arg)
Vowels are free, please use them :)
> +{
> + struct xhci_hcd *xhci;
> + struct usb_hcd *hcd;
> + u32 temp;
> + int i;
> +
> + xhci = (struct xhci_hcd *) arg;
No space needed before "arg".
> +
> + for (i = 0; i < xhci->num_usb3_ports; i++) {
> + temp = xhci_readl(xhci, xhci->usb3_ports[i]);
> + if ((temp & PORT_PLS_MASK) == USB_SS_PORT_LS_COMP_MOD) {
> + /* Compliance Mode Detected. Letting USB Core handle
> + * the Warm Reset */
Multi-line comments are usually in this form:
/*
* Compliance Mode Detected. Letting USB Core handle
* the Warm Reset.
*/
> + xhci_dbg(xhci, "Compliance Mode Detected on port %d!
> "
> + "Attempting recovery routine.\n", i
Don't spread strings across lines, it makes it harder to grep for them.
> +static void compliance_mode_rcvry_timer_init(struct xhci_hcd *xhci)
> +{
> + xhci->port_status_u0 = 0;
> + init_timer(&xhci->comp_mode_rcvry_timer);
> + xhci->comp_mode_rcvry_timer.data = (unsigned long) xhci;
> + xhci->comp_mode_rcvry_timer.function = compliance_mode_rcvry;
> + xhci->comp_mode_rcvry_timer.expires = jiffies +
> + msecs_to_jiffies(COMP_MODE_RCVRY_MSECS);
> + set_timer_slack(&xhci->comp_mode_rcvry_timer, HZ);
That seems like a pretty strict slack time. Can't you make it much
larger? Like at least COMP_MODE_RCVRY_MSECS? You don't need a precise
timer here at all, so give it as much room to be delayed as possible.
> + add_timer(&xhci->comp_mode_rcvry_timer);
> + xhci_dbg(xhci, "Compliance Mode Recovery Timer Initialized.\n");
> +}
> +
> /*
> * Initialize memory for HCD and xHC (one-time init).
> *
> @@ -420,6 +464,9 @@ int xhci_init(struct usb_hcd *hcd)
> retval = xhci_mem_init(xhci, GFP_KERNEL);
> xhci_dbg(xhci, "Finished xhci_init\n");
>
> + /* Initializing Compliance Mode Recovery Data */
> + compliance_mode_rcvry_timer_init(xhci);
There's really no way we can detect this based on the hardware on the
system? Firmware version number? PCI ids? DMI strings? BIOS
versions? Hardware platform types? Processor types? Something?
Anything?
What did Microsoft say in your proposal to them to add this timer for
every Windows system using xhci?
thanks,
greg k-h
--
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
