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
next prev parent 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