public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Stuge <peter@stuge.se>
To: "Alexis R. Cortes" <alexis.cortes@ti.com>
Cc: sarah.a.sharp@linux.intel.com, gregkh@linuxfoundation.org,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	brian.quach@ti.com, jorge.llamas@ti.com
Subject: Re: [PATCH] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
Date: Wed, 1 Aug 2012 22:01:31 +0200	[thread overview]
Message-ID: <20120801200131.15606.qmail@stuge.se> (raw)
In-Reply-To: <50197DC2.5060905@ti.com>

Hi Alexis,

Did you run the patch through checkpatch.pl before submitting it?

I think you will get a bunch of important and completely automatic
feedback when you do that. Please fix everything that the script
mentions.


Alexis R. Cortes wrote:
> This patch is intended to work around a known issue on the
> SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
> between a device and the host past the usual handshake timeout,
> and if that happens on the first insertion, the host controller
> port will enter in Compliance Mode as per xHCI Spec. The patch
> creates a timer which polls every 2 seconds the link state of each
> host controller's port (this by reading the PORTSC register) and
> recovers the port by issuing a Warm reset every time Compliance mode
> is detected.

This is a pretty awful workaround for a teeny tiny hardware error.
You're making systems wake up every two seconds. I don't want that on
my system. I think making the timer settable would be nice.

Also, the patch does more things than what you describe. It adds a
new quirk, and it adds checks to set said quirk for various different
laptop models. Each of those changes (add timer+quirk, and add checks
to set quirk for laptops) should rather be a separate commit.


> @@ -645,6 +657,22 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
>  		/* Update Port Link State for super speed ports*/
>  		if (hcd->speed == HCD_USB3) {
>  			xhci_hub_report_link_state(&status, temp);
> +			/*
> +			 * Verify if all USB3 Ports Have entered U0. Delete compliance
> +			 * mode timer if so.
> +			 */
> +			if (xhci->quirks & XHCI_COMP_MODE_QUIRK) {
> +				if (xhci->port_status_u0 != ((1 << xhci->num_usb3_ports)-1)) {
> +					if ((temp & PORT_PLS_MASK) == XDEV_U0) {
> +						xhci->port_status_u0 |= 1 << wIndex;
> +						if (xhci->port_status_u0 == ((1 << xhci->num_usb3_ports)-1)) {
> +							del_timer_sync(&xhci->comp_mode_recovery_timer);
> +							xhci_dbg(xhci, "Compliance Mode Recovery Timer Deleted. "
> +									"All USB3 ports have entered U0 at least once.\n");
> +						}
> +					}
> +				}
> +			}
>  		}

Is this style consistent with the surrounding code? I would be
surprised. The kernel frequently uses the "early exits" concept.
Please try to embrace it, I think it makes for lovely readable code.

A quote from
http://www.cranked.me/2008/07/spartan-programming-real-man-way-to-do.html

--8<--
Spartan programming strives for simultaneous minimization of all of
the following measures of code complexity:

1. horizontal complexity, that is, the depth of nesting of control
   structures, just as the total line length.

..

8. conditionals, that is the number of if and multiple branch
   switch statements. 
-->8--

This may not be in http://kernel.org/doc/Documentation/CodingStyle
per se, but Chapter 7: Centralized exiting of functions touches on
the issue, includes an example, and I've found it used a lot in the
kernel code. It's a very good idea.


> +++ b/drivers/usb/host/xhci.h
> @@ -1494,6 +1494,7 @@ struct xhci_hcd {
>  #define XHCI_TRUST_TX_LENGTH	(1 << 10)
>  #define XHCI_LPM_SUPPORT	(1 << 11)
>  #define XHCI_INTEL_HOST		(1 << 12)
> +#define XHCI_COMP_MODE_QUIRK	(1 << 13)
>  	unsigned int		num_active_eps;
>  	unsigned int		limit_active_eps;
>  	/* There are two roothubs to keep track of bus suspend info for */
> @@ -1510,6 +1511,11 @@ struct xhci_hcd {
>  	unsigned		sw_lpm_support:1;
>  	/* support xHCI 1.0 spec USB2 hardware LPM */
>  	unsigned		hw_lpm_support:1;
> +	/* Compliance Mode Recovery Data */
> +	struct timer_list	comp_mode_recovery_timer;
> +	u32			port_status_u0;
> +/* Compliance Mode Timer Triggered every 2 seconds */
> +#define COMP_MODE_RCVRY_MSECS 2000

I'm surprised how this get hardcoded from a header file.

I for one would like it to be settable.


Thanks

//Peter

  reply	other threads:[~2012-08-01 20:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-01 19:04 [PATCH] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware Alexis R. Cortes
2012-08-01 20:01 ` Peter Stuge [this message]
2012-08-01 21:18   ` Sarah Sharp
     [not found]     ` <007b01cd702f$1b5e4870$521ad950$@cortes@ti.com>
2012-08-01 23:32       ` Sarah Sharp
  -- strict thread matches above, loose matches on Subject: below --
2012-08-01 22:36 Alexis R. Cortes
2012-08-01 23:23 ` Peter Stuge
2012-08-01 23:51 ` Sarah Sharp
2012-07-31 22:48 Alexis R. Cortes
2012-07-31 23:18 ` Greg KH
2012-07-31 21:19 Alexis Cortes
2012-07-31 21:38 ` Greg KH
     [not found]   ` <50186206.0730b60a.069d.6df1SMTPIN_ADDED@mx.google.com>
2012-07-31 23:16     ` 'Greg KH'

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120801200131.15606.qmail@stuge.se \
    --to=peter@stuge.se \
    --cc=alexis.cortes@ti.com \
    --cc=brian.quach@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jorge.llamas@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sarah.a.sharp@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox