linux-kernel - Re: [PATCH] usb: host: xhci: Compliance Mode port recovery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120622014825.GB3318@kroah.com>
Date:	Thu, 21 Jun 2012 18:48:25 -0700
From:	'Greg KH' <gregkh@...uxfoundation.org>
To:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
Cc:	Alexis Cortes <alexis.cortes@...com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"'Quach, Brian'" <brian.quach@...com>,
	"'Llamas, Jorge'" <jorge.llamas@...com>
Subject: Re: [PATCH] usb: host: xhci: Compliance Mode port recovery

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/