1. 05 2月, 2011 6 次提交
  2. 03 1月, 2011 2 次提交
  3. 24 12月, 2010 1 次提交
    • T
      usb: don't use flush_scheduled_work() · 569ff2de
      Tejun Heo 提交于
      flush_scheduled_work() is being deprecated.  Directly flush or cancel
      work items instead.
      
      * u_ether, isp1301_omap, speedtch conversions are straight-forward.
      
      * ochi-hcd should only flush when quirk_nec() is true as otherwise the
        work wouldn't have been initialized.
      
      * In oti6858, cancel_delayed_work() + flush_scheduled_work() ->
        cancel_delayed_work_sync().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Duncan Sands <duncan.sands@free.fr>
      Cc: linux-usb@vger.kernel.org
      569ff2de
  4. 17 12月, 2010 3 次提交
  5. 11 12月, 2010 5 次提交
  6. 10 12月, 2010 1 次提交
    • S
      xhci: Fix issue with port array setup and buggy hosts. · f8bbeabc
      Sarah Sharp 提交于
      Fix two bugs with the port array setup.
      
      The first bug will only show up with broken xHCI hosts with Extended
      Capabilities registers that have duplicate port speed entries for the same
      port.  The idea with the original code was to set the port_array entry to
      -1 if the duplicate port speed entry said the port was a different speed
      than the original port speed entry.  That would mean that later, the port
      would not be exposed to the USB core. Unfortunately, I forgot a continue
      statement, and the port_array entry would just be overwritten in the next
      line.
      
      The second bug would happen if there are conflicting port speed registers
      (so that some entry in port_array is -1), or one of the hardware port
      registers was not described in the port speed registers (so that some
      entry in port_array is 0).  The code that sets up the usb2_ports array
      would accidentally claim those ports.  That wouldn't really cause any
      user-visible issues, but it is a bug.
      
      This patch should go into the stable trees that have the port array and
      USB 3.0 port disabling prevention patches.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      f8bbeabc
  7. 01 12月, 2010 9 次提交
  8. 29 11月, 2010 1 次提交
  9. 26 11月, 2010 2 次提交
  10. 20 11月, 2010 3 次提交
    • S
      xhci: Don't let the USB core disable SuperSpeed ports. · 6dd0a3a7
      Sarah Sharp 提交于
      Disabling SuperSpeed ports is a Very Bad Thing (TM).  It disables
      SuperSpeed terminations, which means that devices will never connect at
      SuperSpeed on that port.  For USB 2.0/1.1 ports, disabling the port meant
      that the USB core could always get a connect status change later.  That's
      not true with USB 3.0 ports.
      
      Do not let the USB core disable SuperSpeed ports.  We can't rely on the
      device speed in the port status registers, since that isn't valid until
      there's a USB device connected to the port.  Instead, we use the port
      speed array that's created from the Extended Capabilities registers.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NDon Zickus <dzickus@redhat.com>
      Cc: stable@kernel.org
      6dd0a3a7
    • S
      xhci: Setup array of USB 2.0 and USB 3.0 ports. · da6699ce
      Sarah Sharp 提交于
      An xHCI host controller contains USB 2.0 and USB 3.0 ports, which can
      occur in any order in the PORTSC registers.  We cannot read the port speed
      bits in the PORTSC registers at init time to determine the port speed,
      since those bits are only valid when a USB device is plugged into the
      port.
      
      Instead, we read the "Supported Protocol Capability" registers in the xHC
      Extended Capabilities space.  Those describe the protocol, port offset in
      the PORTSC registers, and port count.  We use those registers to create
      two arrays of pointers to the PORTSC registers, one for USB 3.0 ports, and
      another for USB 2.0 ports.  A third array keeps track of the port protocol
      major revision, and is indexed with the internal xHCI port number.
      
      This commit is a bit big, but it should be queued for stable because the "Don't
      let the USB core disable SuperSpeed ports" patch depends on it.  There is no
      other way to determine which ports are SuperSpeed ports without this patch.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NDon Zickus <dzickus@redhat.com>
      Cc: stable@kernel.org
      da6699ce
    • P
      xhci: Fix reset-device and configure-endpoint commands · 7a3783ef
      Paul Zimmerman 提交于
      We have been having problems with the USB-IF Gold Tree tests when plugging
      and unplugging devices from the tree. I have seen that the reset-device
      and configure-endpoint commands, which are invoked from
      xhci_discover_or_reset_device() and xhci_configure_endpoint(), will sometimes
      time out.
      
      After much debugging, I determined that the commands themselves do not actually
      time out, but rather their completion events do not get delivered to the right
      place.
      
      This happens when the command ring has just wrapped around, and it's enqueue
      pointer is left pointing to the link TRB. xhci_discover_or_reset_device() and
      xhci_configure_endpoint() use the enqueue pointer directly as their command
      TRB pointer, without checking whether it's pointing to the link TRB.
      
      When the completion event arrives, if the command TRB is pointing to the link
      TRB, the check against the command ring dequeue pointer in
      handle_cmd_in_cmd_wait_list() fails, so the completion inside the command does
      not get signaled.
      
      The patch below fixes the timeout problem for me.
      
      This should be queued for the 2.6.35 and 2.6.36 stable trees.
      Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      7a3783ef
  11. 18 11月, 2010 2 次提交
  12. 17 11月, 2010 5 次提交