Skip to content

cloud-kernel
cloud-kernel

bug2833 / cloud-kernel
与 Fork 源项目一致

Fork自 openanolis / cloud-kernel

通知 1
Star 0
Fork 0
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 12 11月, 2010 2 次提交
  3. 11 11月, 2010 1 次提交
  5. 23 10月, 2010 7 次提交
  7. 11 8月, 2010 7 次提交
  9. 27 7月, 2010 1 次提交
    • S
      USB: xhci: Set EP0 dequeue ptr after reset of configured device. · 2d1ee590
      由 Sarah Sharp 提交于 
      When a configured device is reset, the control endpoint's ring is reused.
If control transfers to the device were issued before the device is reset,
the dequeue pointer will be somewhere in the middle of the ring.  If the
device is then issued an address with the set address command, the xHCI
driver must provide a valid input context for control endpoint zero.

The original code would give the hardware the original input context,
which had a dequeue pointer set to the top of the ring.  This would cause
the host to re-execute any control transfers until it reached the ring's
enqueue pointer.  When issuing a set address command for a device that has
just been configured and then reset, use the control endpoint's enqueue
pointer as the hardware's dequeue pointer.

Assumption:  All control transfers will be completed or cancelled before
the set address command is issued to the device.  If there are any
outstanding control transfers, this code will not work.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2d1ee590
  11. 05 6月, 2010 3 次提交
  13. 21 5月, 2010 6 次提交
    • S
      USB: xhci: Set stream ID to 0 after cleaning up stalls. · 5e5cf6fc
      由 Sarah Sharp 提交于 
      After using state stored in xhci_virt_ep to clean up a stalled endpoint,
be sure to set the stalled stream ID back to 0.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5e5cf6fc
    • S
      USB: xhci: Avoid double free after streams are disabled. · 8a007748
      由 Sarah Sharp 提交于 
      When a device is disconnected, xhci_free_virt_device() is called.  Ramya
found that if the device had streams enabled, and then the driver freed
the streams with a call to usb_free_streams(), then about a minute after
he had called this, his machine crashed with a Bad DMA error.  It turns
out that xhci_free_virt_device() would attempt to free the endpoint's
stream_info data structure if it wasn't NULL, and the free streams
function was not setting it to NULL after freeing it.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NRamya Desai <ramya.desai@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8a007748
    • A
      USB: remove the usb_host_ss_ep_comp structure · 842f1690
      由 Alan Stern 提交于 
      This patch (as1375) eliminates the usb_host_ss_ep_comp structure used
for storing a dynamically-allocated copy of the SuperSpeed endpoint
companion descriptor.  The SuperSpeed descriptor is placed directly in
the usb_host_endpoint structure, alongside the standard endpoint
descriptor.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      842f1690
    • S
      USB: xhci: Correct assumptions about number of rings per endpoint. · e9df17eb
      由 Sarah Sharp 提交于 
      Much of the xHCI driver code assumes that endpoints only have one ring.
Now an endpoint can have one ring per enabled stream ID, so correct that
assumption.  Use functions that translate the stream_id field in the URB
or the DMA address of a TRB into the correct stream ring.

Correct the polling loop to print out all enabled stream rings.  Make the
URB cancellation routine find the correct stream ring if the URB has
stream_id set.  Make sure the URB enqueueing routine does the same.  Also
correct the code that handles stalled/halted endpoints.

Check that commands and registers that can take stream IDs handle them
properly.  That includes ringing an endpoint doorbell, resetting a
stalled/halted endpoint, and setting a transfer ring dequeue pointer
(since that command can set the dequeue pointer in a stream context or an
endpoint context).

Correct the transfer event handler to translate a TRB DMA address into the
stream ring it was enqueued to.  Make the code to allocate and prepare TD
structures adds the TD to the right td_list for the stream ring.  Make
sure the code to give the first TRB in a TD to the hardware manipulates
the correct stream ring.

When an endpoint stalls, store the stream ID of the stream ring that
stalled in the xhci_virt_ep structure.  Use that instead of the stream ID
in the URB, since an URB may be re-used after it is given back after a
non-control endpoint stall.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e9df17eb
    • S
      USB: xhci: Add memory allocation for USB3 bulk streams. · 8df75f42
      由 Sarah Sharp 提交于 
      Add support for allocating streams for USB 3.0 bulk endpoints.  See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.

When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings.  The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array".  This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.

The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries).  These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.

Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure.  The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event.  For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.

Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place.  Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.

We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls.  (It is
not advised, however, since it is a waste of resources and time.)

Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command.  It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command.  We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth.  The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).

If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers.  It's an unavoidable consequence
of broken host controller hardware.

Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8df75f42
    • S
      USB: xhci: Fix issue with set interface after stall. · 1624ae1c
      由 Sarah Sharp 提交于 
      When the USB core installs a new interface, it unconditionally clears the
halts on all the endpoints on the new interface.  Usually the xHCI host
needs to know when an endpoint is reset, so it can change its internal
endpoint state.  In this case, it doesn't care, because the endpoints were
never halted in the first place.

To avoid issuing a redundant Reset Endpoint command, the xHCI driver looks
at xhci_virt_ep->stopped_td to determine if the endpoint was actually
halted.  However, the functions that handle the stall never set that
variable to NULL after it dealt with the stall.  So if an endpoint stalled
and a Reset Endpoint command completed, and then the class driver tried to
install a new alternate setting, the xHCI driver would access the old
xhci_virt_ep->stopped_td pointer.  A similar problem occurs if the
endpoint has been stopped to cancel a transfer.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1624ae1c
  15. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      由 Tejun Heo 提交于 
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  17. 19 3月, 2010 2 次提交
  19. 03 3月, 2010 5 次提交
  21. 12 12月, 2009 4 次提交
    • S
      USB: xhci: Make reverting an alt setting "unfailable". · 74f9fe21
      由 Sarah Sharp 提交于 
      When a driver wants to switch to a different alternate setting for an
interface, the USB core will (soon) check whether there is enough
bandwidth.  Once the new alternate setting is installed in the xHCI
hardware, the USB core will send a USB_REQ_SET_INTERFACE control
message.  That can fail in various ways, and the USB core needs to be
able to reinstate the old alternate setting.

With the old code, reinstating the old alt setting could fail if the
there's not enough memory to allocate new endpoint rings.  Keep
around a cache of (at most 31) endpoint rings for this case.  When we
successfully switch the xHCI hardware to the new alt setting, the old
alt setting's rings will be stored in the cache.  Therefore we'll
always have enough rings to satisfy a conversion back to a previous
device setting.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      74f9fe21
    • S
      USB: xhci: Add watchdog timer for URB cancellation. · 6f5165cf
      由 Sarah Sharp 提交于 
      In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB.  We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command.  Since URBs can be canceled in interrupt context, we
can't wait on that command.  The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler.  If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.

Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued.  If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer().  Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit.  If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.

Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending).  If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands.  If del_timer() fails, we leave the number of pending
stop endpoint commands alone.  In either case, we clear the
EP_HALT_PENDING flag.

The timer will decrement the number of pending stop endpoint commands
once it obtains the lock.  If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying.  The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.

Various other places in the driver need to check whether the xHCI host
is dying.  If the interrupt handler ever notices, it should immediately
stop processing events.  The URB enqueue function should also return
-ESHUTDOWN.  The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back.  When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway).  The debugging
polling loop should stop polling if the host is dying.

When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync().  It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6f5165cf
    • S
      USB: xhci: Re-purpose xhci_quiesce(). · 4f0f0bae
      由 Sarah Sharp 提交于 
      xhci_quiesce() is basically a no-op right now.  It's only called if
HC_IS_RUNNING() is true, and the body of the function consists of a
BUG_ON if HC_IS_RUNNING() is false.  For the new xHCI watchdog timer, we
need a new function that clears the xHCI running bit in the command
register, but doesn't wait for the halt status to show up in the status
register.  Re-purpose xhci_quiesce() to do that.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4f0f0bae
    • S
      USB: xhci: Handle URB cancel, complete and resubmit race. · 678539cf
      由 Sarah Sharp 提交于 
      In the old code, there was a race condition between the stop endpoint
command and the URB submission process.  When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell.  The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.

However, the following race condition could occur with the old code:

1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
   endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
   (at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted.  An
   event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
   canceled, decrements ep->cancels_pending to 0, and removes it from the to
   be canceled list.
5. The event handler drops the lock and gives back the URB.  The
   completion handler requeues the URB (or a different driver enqueues a new
   URB).  This causes the endpoint's doorbell to be rung, since
   ep->cancels_pending == 0.  The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
   Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
   ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command.  The
   handler assumes the endpoint is stopped, but it isn't.  It attempts to
   move the dequeue pointer or change TDs to cancel the second URB, while the
   hardware is actively accessing the endpoint ring.

To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING.  When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet.  The endpoint doorbell should not be rung when this
is set.  Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell.  ep->cancels_pending is eliminated, because it is no longer
used.

Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty.  All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      678539cf
  23. 10 10月, 2009 1 次提交