1. 13 Sep, 2012 9 commits
    • Felipe Balbi's avatar
      usb: host: xhci: sparse fixes · ed384bd3
      Felipe Balbi authored
      drivers/usb/host/xhci.c:1826:14: warning: symbol 'xhci_get_block_size' was not declared. Should it be static?
      drivers/usb/host/xhci.c:1844:14: warning: symbol 'xhci_get_largest_overhead' was not declared. Should it be static?
      drivers/usb/host/xhci-ring.c:2304:36: warning: context imbalance in 'handle_tx_event' - unexpected unlock
      drivers/usb/host/xhci-hub.c:425:6: warning: symbol 'xhci_set_remote_wake_mask' was not declared. Should it be static?
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      ed384bd3
    • Elric Fu's avatar
      xHCI: handle command after aborting the command ring · b63f4053
      Elric Fu authored
      According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
      after aborting a command on the command ring, xHC will
      generate a command completion event with its completion
      code set to Command Ring Stopped at least. If a command is
      currently executing at the time of aborting a command, xHC
      also generate a command completion event with its completion
      code set to Command Abort. When the command ring is stopped,
      software may remove, add, or rearrage Command Descriptors.
      
      To cancel a command, software will initialize a command
      descriptor for the cancel command, and add it into a
      cancel_cmd_list of xhci. When the command ring is stopped,
      software will find the command trbs described by command
      descriptors in cancel_cmd_list and modify it to No Op
      command. If software can't find the matched trbs, we can
      think it had been finished.
      
      This patch should be backported to kernels as old as 3.0, that contain
      the commit 7ed603ec "xhci: Add an
      assertion to check for virt_dev=0 bug." That commit papers over a NULL
      pointer dereference, and this patch fixes the underlying issue that
      caused the NULL pointer dereference.
      Signed-off-by: default avatarElric Fu <elricfu1@gmail.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: default avatarMiroslav Sabljic <miroslav.sabljic@avl.com>
      Cc: stable@vger.kernel.org
      b63f4053
    • Elric Fu's avatar
      xHCI: cancel command after command timeout · 6e4468b9
      Elric Fu authored
      The patch is used to cancel command when the command isn't
      acknowledged and a timeout occurs.
      
      This patch should be backported to kernels as old as 3.0, that contain
      the commit 7ed603ec "xhci: Add an
      assertion to check for virt_dev=0 bug." That commit papers over a NULL
      pointer dereference, and this patch fixes the underlying issue that
      caused the NULL pointer dereference.
      Signed-off-by: default avatarElric Fu <elricfu1@gmail.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: default avatarMiroslav Sabljic <miroslav.sabljic@avl.com>
      Cc: stable@vger.kernel.org
      6e4468b9
    • Elric Fu's avatar
      xHCI: add aborting command ring function · b92cc66c
      Elric Fu authored
      Software have to abort command ring and cancel command
      when a command is failed or hang. Otherwise, the command
      ring will hang up and can't handle the others. An example
      of a command that may hang is the Address Device Command,
      because waiting for a SET_ADDRESS request to be acknowledged
      by a USB device is outside of the xHC's ability to control.
      
      To cancel a command, software will initialize a command
      descriptor for the cancel command, and add it into a
      cancel_cmd_list of xhci.
      
      Sarah: Fixed missing newline on "Have the command ring been stopped?"
      debugging statement.
      
      This patch should be backported to kernels as old as 3.0, that contain
      the commit 7ed603ec "xhci: Add an
      assertion to check for virt_dev=0 bug." That commit papers over a NULL
      pointer dereference, and this patch fixes the underlying issue that
      caused the NULL pointer dereference.
      Signed-off-by: default avatarElric Fu <elricfu1@gmail.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: default avatarMiroslav Sabljic <miroslav.sabljic@avl.com>
      Cc: stable@vger.kernel.org
      b92cc66c
    • Elric Fu's avatar
      xHCI: add cmd_ring_state · c181bc5b
      Elric Fu authored
      Adding cmd_ring_state for command ring. It helps to verify
      the current command ring state for controlling the command
      ring operations.
      
      This patch should be backported to kernels as old as 3.0.  The commit
      7ed603ec "xhci: Add an assertion to
      check for virt_dev=0 bug." papers over the NULL pointer dereference that
      I now believe is related to a timed out Set Address command.  This (and
      the four patches that follow it) contain the real fix that also allows
      VIA USB 3.0 hubs to consistently re-enumerate during the plug/unplug
      stress tests.
      Signed-off-by: default avatarElric Fu <elricfu1@gmail.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: default avatarMiroslav Sabljic <miroslav.sabljic@avl.com>
      Cc: stable@vger.kernel.org
      c181bc5b
    • Greg Kroah-Hartman's avatar
      USB: core: remove unused dbg() call in message.c · c2d57aec
      Greg Kroah-Hartman authored
      It's not needed, and commented out, so just remove it.
      
      Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2d57aec
    • Greg Kroah-Hartman's avatar
      USB: atm: usbatm: fix up debug printing code · 34ad569f
      Greg Kroah-Hartman authored
      If VERBOSE_DEBUG was enabled, lots of build errors happend (obviously no
      one uses this mode.)  So fix that up, and get rid of the dbg() call, and
      use dev_dbg() like the rest of the driver does.
      
      Cc: Duncan Sands <duncan.sands@free.fr>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      34ad569f
    • Greg Kroah-Hartman's avatar
      USB: serial: add zte_ev.c driver · 799ee924
      Greg Kroah-Hartman authored
      This adds a driver for the zte_ev set of usb to serial devices.  It is
      based on a patch floating around the internet that modified the generic
      usb-serial driver to only work for this type of device.
      
      I've left comments in the code that I think show the data commands being
      sent to the device, which I'm guessing come from a usb analyzer.  Maybe
      they can help others out as well.
      
      Many thanks to nirinA raseliarison for pointing the original patch out
      to me, and for testing that the driver works properly.
      Tested-by: default avatarnirinA raseliarison <nirina.raseliarison@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      799ee924
    • Greg Kroah-Hartman's avatar
      USB: serial: move usb_serial_debug_data to use %*ph · 1db9e45c
      Greg Kroah-Hartman authored
      Now that we have a printk modifier for data streams, use it instead of
      rolling our own.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1db9e45c
  2. 12 Sep, 2012 14 commits
  3. 11 Sep, 2012 14 commits
  4. 10 Sep, 2012 3 commits