Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 04 2月, 2016 7 次提交
    • M
      xhci: USB 3.1 add default Speed Attributes to SuperSpeedPlus device capability · 5da665fc
      由 Mathias Nyman 提交于 
      If a xhci controller does not provide a protocol speed ID (PSI) table, a
default one should be used instead. Add the default values to the
SuperSpeedPlus device capability. Overwrite the default ones if a PSI table
exists. See xHCI 1.1 sectio 7.2.2.1.1 for more info
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5da665fc
    • M
      xhci: set roothub speed to USB_SPEED_SUPER_PLUS for USB3.1 capable controllers · 2c0e06f8
      由 Mathias Nyman 提交于 
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2c0e06f8
    • M
      xhci: Make sure xhci handles USB_SPEED_SUPER_PLUS devices. · 0caf6b33
      由 Mathias Nyman 提交于 
      In most cases the devices with the speed set to USB_SPEED_SUPER_PLUS
are handled like regular SuperSpeed devices.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0caf6b33
    • A
      USB: EHCI: improvements to unlink_empty_async_suspended() · 8df0d77d
      由 Alan Stern 提交于 
      unlink_empty_async_suspended() is marked __maybe_unused.  This is
because its caller, ehci_bus_suspend(), is protected by "#ifdef
CONFIG_PM".  We should use the same protection here instead of
__maybe_unused.

unlink_empty_async_suspended() gets called only when the root hub is
suspended.  It's silly for it to call start_iaa_cycle() at such a
time; the IAA mechanism doesn't work when the root hub isn't running.
It should call end_unlink_async() instead.  But even this isn't
necessary, since there already is a call to end_iaa_cycle() right
before the call to unlink_empty_async_suspended().  All we have to do
is interchange the two subroutine calls.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8df0d77d
    • A
      USB: EHCI: add a delay when unlinking an active QH · 87d61912
      由 Alan Stern 提交于 
      Michael Reutman reports that an AMD/ATI EHCI host controller on one of
his computers does not stop transferring data when an active bulk QH
is unlinked from the async schedule.  Apparently that host controller
fails to implement the IAA mechanism correctly when an active QH is
unlinked.  This leads to data corruption, because the controller
continues to update the QH in memory when the driver doesn't expect
it.  As a result, the next URB submitted for that QH can hang, because
the link pointers for the TD queue have been messed up.  This
misbehavior is observed quite regularly.

To be fair, the EHCI spec (section 4.8.2) says that active QHs should
not be unlinked.  It goes on to recommend a procedure that involves
waiting for the QH to go inactive before unlinking it.  In the real
world this is impractical, not least because the QH may _never_ go
inactive.  (What were they thinking?)  Sometimes we have no choice but
to unlink an active QH.

In an attempt to avoid the problems that can ensue, this patch changes
how the driver decides when the unlink is complete.  In addition to
waiting through two IAA cycles, in cases where the QH was not known to
be inactive beforehand we now wait until a 2-ms period has elapsed
with the host controller making no change to the QH data structure
(the hw_current and hw_token fields in particular).  The intuition
here is that after such a long period, the endpoint must be NAKing and
hopefully the QH has been dropped from the host controller's internal
cache.  There's no way to know if this reasoning is really valid --
the spec is no help in this regard -- but at least this approach fixes
Michael's problem.

The test for whether the QH is already known to be inactive involves
the reason for unlinking the QH originally.  If it was unlinked
because it had halted, or it stopped in response to a short read, or
it overlaid a dummy TD (a silicon bug), then it certainly is inactive.
If it was unlinked because the TD queue was empty and no TDs have been
added to the queue in the meantime, then it must be inactive.  Or if
the hardware status indicates that the QH is currently halted (even if
that wasn't the reason for unlinking it), then it is inactive.
Otherwise, if none of those checks apply, we go through the 2-ms
delay.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NMichael Reutman <mreutman@epiqsolutions.com>
Tested-by: NMichael Reutman <mreutman@epiqsolutions.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      87d61912
    • A
      USB: EHCI: improve handling of the ehci->iaa_in_progress flag · f96fba0d
      由 Alan Stern 提交于 
      This patch improves the way ehci-hcd handles the iaa_in_progress flag.
The current code is somewhat careless in this regard:

	The flag is meaningless when the root hub isn't running, most
	particularly after the root hub has been suspended.  But in
	start_iaa_cycle(), the driver checks the flag before checking
	the root hub's state.  They should be checked in the opposite
	order.

	That routine also sets the flag too early, before it has
	definitely committed to starting an IAA cycle.

	The flag is turned off in end_unlink_async().  Upcoming
	changes will call that routine at other times, not just at the
	end of an IAA cycle.  The two actions are logically separate
	(although related), so we separate out a new routine to be
	called in place of end_unlink_async() whenever an IAA cycle
	ends: end_iaa_cycle().

	iaa_in_progress should be turned off when the root hub is
	suspended -- we certainly don't want it still to be set when
	the root hub resumes.  Therefore the call to
	end_unlink_async() in ehci_bus_suspend() should also be
	replaced with a call to end_iaa_cycle().
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f96fba0d
    • A
      USB: EHCI: store reason for unlinking a QH · fcc5184e
      由 Alan Stern 提交于 
      This patch replaces the "exception" bitflag in the ehci_qh structure
with a more explicit "unlink_reason" bitmask.  This is for use in the
following patch, where we will need to have a good idea of the
reason for unlinking a QH, not just "something exceptional happened".
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NMichael Reutman <mreutman@epiqsolutions.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcc5184e
  3. 25 1月, 2016 17 次提交
  5. 23 12月, 2015 2 次提交
  7. 12 12月, 2015 1 次提交
    • M
      xhci: fix usb2 resume timing and races. · f69115fd
      由 Mathias Nyman 提交于 
      According to USB 2 specs ports need to signal resume for at least 20ms,
in practice even longer, before moving to U0 state.
Both host and devices can initiate resume.

On device initiated resume, a port status interrupt with the port in resume
state in issued. The interrupt handler tags a resume_done[port]
timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.
Root hub timer requests for port status, finds the port in resume state,
checks if resume_done[port] timestamp passed, and set port to U0 state.

On host initiated resume, current code sets the port to resume state,
sleep 20ms, and finally sets the port to U0 state. This should also
be changed to work in a similar way as the device initiated resume, with
timestamp tagging, but that is not yet tested and will be a separate
fix later.

There are a few issues with this approach

1. A host initiated resume will also generate a resume event. The event
   handler will find the port in resume state, believe it's a device
   initiated resume, and act accordingly.

2. A port status request might cut the resume signalling short if a
   get_port_status request is handled during the host resume signalling.
   The port will be found in resume state. The timestamp is not set leading
   to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.
   get_port_status will proceed with moving the port to U0.

3. If an error, or anything else happens to the port during device
   initiated resume signalling it will leave all the device resume
   parameters hanging uncleared, preventing further suspend, returning
   -EBUSY, and cause the pm thread to busyloop trying to enter suspend.

Fix this by using the existing resuming_ports bitfield to indicate that
resume signalling timing is taken care of.
Check if the resume_done[port] is set before using it for timestamp
comparison, and also clear out any resume signalling related variables
if port is not in U0 or Resume state

This issue was discovered when a PM thread busylooped, trying to runtime
suspend the xhci USB 2 roothub on a Dell XPS

Cc: stable <stable@vger.kernel.org>
Reported-by: NDaniel J Blueman <daniel@quora.org>
Tested-by: NDaniel J Blueman <daniel@quora.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f69115fd
  9. 05 12月, 2015 7 次提交
  11. 02 12月, 2015 6 次提交