mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "'Greg KH'" <gregkh@linuxfoundation.org>
To: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alexis Cortes <alexis.cortes@ti.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, "'Quach,
	Brian'" <brian.quach@ti.com>,
	"'Llamas, Jorge'" <jorge.llamas@ti.com>
Subject: Re: [PATCH] usb: host: xhci: Compliance Mode port recovery
Date: Thu, 21 Jun 2012 18:48:25 -0700	[thread overview]
Message-ID: <20120622014825.GB3318@kroah.com> (raw)
In-Reply-To: <20120622000858.GB629@xanatos>

On Thu, Jun 21, 2012 at 05:08:58PM -0700, Sarah Sharp wrote:
> On Thu, Jun 21, 2012 at 12:31:12PM -0500, Alexis Cortes wrote:
> > Hi Greg,
> > 
> > I understand your concerns, however as I mentioned before, any xHCI host
> > that has this particular re-driver between its root-ports and the physical
> > ports of the system will be subject to suffer of this compliance mode issue
> > (once the port has entered compliance mode, it becomes unusable so no device
> > that is plugged to that port will work until a warm reset is applied to it).
> > For a system that has this re-driver, this problem could hit about 20%-40%
> > of the times (however this percentage is subject to the quality of the
> > internal connection) and unfortunately there is no way to programmatically
> > detect if this re-driver is on the system.
> > 
> > As Sarah proposed, we certainly can apply this patch as a module parameter
> > disabled by default and let know our clients that we know are using this
> > re-driver to enable the feature to avoid the issue.
> 
> I don't think that would work very well.  Are those clients supposed to
> notify Linux OSVs when a system will ship with that redriver so they can
> turn it on for Linux preloads of those systems?  What about the average
> Linux user who installs Linux themselves?
> 
> An alternative approach, since you know which clients are using the
> re-driver, is to just add a quirk, and get them to tell us when they're
> shipping a system with your redriver.  Then we can turn it on in the
> mainline kernel, all Linux distros will pick it up, and we will avoid
> disgruntled users.
> 
> Or we can just modify the timer to a more reasonable value like 10
> seconds, and users will just have to put up with the longer enumeration
> times.
> 
> Greg, what about exporting a sysfs file to change the polling interval?
> We could run the timer every 2 seconds by default, but get powertop to
> add a new setting for turning the interval off.

Ick, a sysfs file is almost as bad as a kernel module option, how are
you going to tell users / distros when to turn it off or not if you
don't know if it is needed or not?

We really need a way to determine the hardware here.

Alexis, what are you doing on Windows for this?  Surely you can't be
turning a timer on every 2 seconds for all Windows systems in the world,
are you?

thanks,

greg k-h

  reply	other threads:[~2012-06-22  1:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <002801cd4e68$a4b4f3a0$ee1edae0$@cortes@ti.com>
2012-06-19 22:39 ` Sarah Sharp
     [not found]   ` <004101cd4f33$755e8eb0$601bac10$@cortes@ti.com>
2012-06-21  0:07     ` Sarah Sharp
2012-06-21  0:32       ` Greg KH
     [not found]         ` <003001cd4fd3$a7648950$f62d9bf0$@cortes@ti.com>
2012-06-22  0:08           ` Sarah Sharp
2012-06-22  1:48             ` 'Greg KH' [this message]
2012-06-22 16:44               ` Sarah Sharp
     [not found]         ` <4fe35a44.82143c0a.4e83.62a8SMTPIN_ADDED@mx.google.com>
2012-06-22  1:40           ` 'Greg KH'
     [not found]       ` <003701cd4fde$fd969290$f8c3b7b0$@cortes@ti.com>
2012-06-22 16:32         ` Sarah Sharp
2012-06-22 16:47           ` Greg KH
     [not found]             ` <4fe9f0c8.04c1b60a.11cc.3ca4SMTPIN_ADDED@mx.google.com>
2012-06-26 17:51               ` 'Greg KH'
     [not found]                 ` <4ffcad84.6710b60a.2b1a.0065SMTPIN_ADDED@mx.google.com>
2012-07-11 15:06                   ` 'Greg KH'
     [not found]                     ` <5016ed18.0730b60a.1211.ffffe227SMTPIN_ADDED@mx.google.com>
2012-07-30 21:47                       ` '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=20120622014825.GB3318@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alexis.cortes@ti.com \
    --cc=brian.quach@ti.com \
    --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

Powered by JetHome