1. 06 Feb, 2013 7 commits
    • Sarah Sharp's avatar
      USB: Ignore xHCI Reset Device status. · 6cee667e
      Sarah Sharp authored
      commit 8b8132bc upstream.
      
      When the USB core finishes reseting a USB device, the xHCI driver sends
      a Reset Device command to the host.  The xHC then updates its internal
      representation of the USB device to the 'Default' device state.  If the
      device was already in the Default state, the xHC will complete the
      command with an error status.
      
      If a device needs to be reset several times during enumeration, the
      second reset will always fail because of the xHCI Reset Device command.
      This can cause issues during enumeration.
      
      For example, usb_reset_and_verify_device calls into hub_port_init in a
      loop.  Say that on the first call into hub_port_init, the device is
      successfully reset, but doesn't respond to several set address control
      transfers.  Then the port will be disabled, but the udev will remain in
      tact.  usb_reset_and_verify_device will call into hub_port_init again.
      
      On the second call into hub_port_init, the device will be reset, and the
      xHCI driver will issue a Reset Device command.  This command will fail
      (because the device is already in the Default state), and
      usb_reset_and_verify_device will fail.  The port will be disabled, and
      the device won't be able to enumerate.
      
      Fix this by ignoring the return value of the HCD reset_device callback.
      
      This commit should be backported to kernels as old as 3.2, that contain
      the commit 75d7cf72 "usbcore: refine
      warm reset logic".
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6cee667e
    • Sarah Sharp's avatar
      USB: Handle auto-transition from hot to warm reset. · 330a5270
      Sarah Sharp authored
      commit 1c7439c6 upstream.
      
      USB 3.0 hubs and roothubs will automatically transition a failed hot
      reset to a warm (BH) reset.  In that case, the warm reset change bit
      will be set, and the link state change bit may also be set.  Change
      hub_port_finish_reset to unconditionally clear those change bits for USB
      3.0 hubs.  If these bits are not cleared, we may lose port change events
      from the roothub.
      
      This commit should be backported to kernels as old as 3.2, that contain
      the commit 75d7cf72 "usbcore: refine
      warm reset logic".
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      330a5270
    • Sarah Sharp's avatar
      xhci: Handle HS bulk/ctrl endpoints that don't NAK. · 4a2b6c95
      Sarah Sharp authored
      commit 55c1945e upstream.
      
      A high speed control or bulk endpoint may have bInterval set to zero,
      which means it does not NAK.  If bInterval is non-zero, it means the
      endpoint NAKs at a rate of 2^(bInterval - 1).
      
      The xHCI code to compute the NAK interval does not handle the special
      case of zero properly.  The current code unconditionally subtracts one
      from bInterval and uses it as an exponent.  This causes a very large
      bInterval to be used, and warning messages like these will be printed:
      
      usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes
      
      This may cause the xHCI host hardware to reject the Configure Endpoint
      command, which means the HS device will be unusable under xHCI ports.
      
      This patch should be backported to kernels as old as 2.6.31, that contain
      commit dfa49c4a "USB: xhci - fix math in
      xhci_get_endpoint_interval()".
      Reported-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Suggested-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4a2b6c95
    • Johannes Berg's avatar
      mac80211: use del_timer_sync for final sta cleanup timer deletion · ac2c3982
      Johannes Berg authored
      commit a56f992c upstream.
      
      This is a very old bug, but there's nothing that prevents the
      timer from running while the module is being removed when we
      only do del_timer() instead of del_timer_sync().
      
      The timer should normally not be running at this point, but
      it's not clearly impossible (or we could just remove this.)
      Tested-by: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ac2c3982
    • Alexander Graf's avatar
      virtio-blk: Don't free ida when disk is in use · 63dddb49
      Alexander Graf authored
      commit f4953fe6 upstream.
      
      When a file system is mounted on a virtio-blk disk, we then remove it
      and then reattach it, the reattached disk gets the same disk name and
      ids as the hot removed one.
      
      This leads to very nasty effects - mostly rendering the newly attached
      device completely unusable.
      
      Trying what happens when I do the same thing with a USB device, I saw
      that the sd node simply doesn't get free'd when a device gets forcefully
      removed.
      
      Imitate the same behavior for vd devices. This way broken vd devices
      simply are never free'd and newly attached ones keep working just fine.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      63dddb49
    • Sergei Shtylyov's avatar
      usb: musb: core: print new line in the driver banner again · 9d38cd59
      Sergei Shtylyov authored
      commit 2ac788f7 upstream.
      
      Commit 5c8a86e1 (usb: musb: drop unneeded
      musb_debug trickery) erroneously removed '\n' from the driver's banner.
      Concatenate all the banner substrings while adding it back...
      Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9d38cd59
    • Sebastian Andrzej Siewior's avatar
      usb: gadget: dummy: fix enumeration with g_multi · 7cce8398
      Sebastian Andrzej Siewior authored
      commit 1d16638e upstream.
      
      If we do have endpoints named like "ep-a" then bEndpointAddress is
      counted internally by the gadget framework.
      
      If we do have endpoints named like "ep-1" then bEndpointAddress is
      assigned from the digit after "ep-".
      
      If we do have both, then it is likely that after we used up the
      "generic" endpoints we will use the digits and thus assign one
      bEndpointAddress to multiple endpoints.
      
      This theory can be proofed by using the completely enabled g_multi.
      Without this patch, the mass storage won't enumerate and times out
      because it shares endpoints with RNDIS.
      
      This patch also adds fills up the endpoints list so we have in total
      endpoints 1 to 15 in + out available while some of them are restricted
      to certain types like BULK or ISO. Without this change the nokia gadget
      won't load because the system does not provide enough (BULK) endpoints
      but it did before ep-a - ep-f were removed.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7cce8398
  2. 16 Jan, 2013 33 commits