1. 26 3月, 2013 1 次提交
  2. 16 3月, 2013 1 次提交
  3. 04 3月, 2013 1 次提交
    • R
      ACPI / glue: Add .match() callback to struct acpi_bus_type · 53540098
      Rafael J. Wysocki 提交于
      USB uses the .find_bridge() callback from struct acpi_bus_type
      incorrectly, because as a result of the way it is used by USB every
      device in the system that doesn't have a bus type or parent is
      passed to usb_acpi_find_device() for inspection.
      
      What USB actually needs, though, is to call usb_acpi_find_device()
      for USB ports that don't have a bus type defined, but have
      usb_port_device_type as their device type, as well as for USB
      devices.
      
      To fix that replace the struct bus_type pointer in struct
      acpi_bus_type used for matching devices to specific subsystems
      with a .match() callback to be used for this purpose and update
      the users of struct acpi_bus_type, including USB, accordingly.
      Define the .match() callback routine for USB, usb_acpi_bus_match(),
      in such a way that it will cover both USB devices and USB ports
      and remove the now redundant .find_bridge() callback pointer from
      usb_acpi_bus.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NJeff Garzik <jgarzik@pobox.com>
      53540098
  4. 24 2月, 2013 1 次提交
    • M
      usb: forbid memory allocation with I/O during bus reset · 4d769def
      Ming Lei 提交于
      If one storage interface or usb network interface(iSCSI case) exists in
      current configuration, memory allocation with GFP_KERNEL during
      usb_device_reset() might trigger I/O transfer on the storage interface
      itself and cause deadlock because the 'us->dev_mutex' is held in
      .pre_reset() and the storage interface can't do I/O transfer when the
      reset is triggered by other interface, or the error handling can't be
      completed if the reset is triggered by the storage itself (error
      handling path).
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David Decotigny <david.decotigny@google.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Oliver Neukum <oneukum@suse.de>
      Reviewed-by: NJiri Kosina <jkosina@suse.cz>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d769def
  5. 23 2月, 2013 1 次提交
  6. 07 2月, 2013 1 次提交
  7. 29 1月, 2013 1 次提交
  8. 26 1月, 2013 6 次提交
  9. 25 1月, 2013 2 次提交
    • A
      USB: fix sign-extension bug in the hub driver · bdb6bc06
      Alan Stern 提交于
      This patch (as1646) fixes a long-standing bug in the USB hub driver.
      Upon conversion from char to unsigned long, the bytes in the status
      buffer are subject to unwanted sign extension.  The bytes should be
      declared as u8 rather than char, to prevent this.
      
      This effects of this bug are minimal.  The hub driver may end up doing
      a little unnecessary extra work because it thinks events have occurred
      on some ports when they really haven't.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bdb6bc06
    • L
      usb: Using correct way to clear usb3.0 device's remote wakeup feature. · 54a3ac0c
      Lan Tianyu 提交于
      Usb3.0 device defines function remote wakeup which is only for interface
      recipient rather than device recipient. This is different with usb2.0 device's
      remote wakeup feature which is defined for device recipient. According usb3.0
      spec 9.4.5, the function remote wakeup can be modified by the SetFeature()
      requests using the FUNCTION_SUSPEND feature selector. This patch is to use
      correct way to disable usb3.0 device's function remote wakeup after suspend
      error and resuming.
      
      This should be backported to kernels as old as 3.4, that contain the
      commit 623bef9e "USB/xhci: Enable remote
      wakeup for USB3 devices."
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      54a3ac0c
  10. 22 1月, 2013 1 次提交
    • L
      USB: Set usb port's DeviceRemovable according acpi information · d2123fd9
      Lan Tianyu 提交于
      ACPI provide "_PLD" and "_UPC" aml methods to describe usb port
      visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable()
      to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in
      the rh_call_control(). When hub descriptor request is issued at first time,
      usb port device isn't created and usb port is not bound with acpi. So first
      hub descriptor request is not changed based on ACPI information. After usb
      port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure()
      and then set hub port's DeviceRemovable according ACPI information and this also works
      for non-root hub.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2123fd9
  11. 21 1月, 2013 3 次提交
  12. 19 1月, 2013 1 次提交
  13. 12 1月, 2013 4 次提交
  14. 04 1月, 2013 12 次提交
    • S
      USB: Refactor hub_port_wait_reset. · 470f0be8
      Sarah Sharp 提交于
      Refactor hub_port_wait_reset into a small loop to wait for the port
      reset to be complete, and then a larger block to deal with the final
      port status.  This patch should not change any current behavior.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      470f0be8
    • S
      USB: Use helper function hub_set_port_link_state · c2f60db7
      Sarah Sharp 提交于
      Change the code that manually issues a Set Port Feature(Link State) to
      use the new helper function hub_set_port_link_state().
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      c2f60db7
    • S
      USB: Fix connected device switch to Inactive state. · d3b9d7a9
      Sarah Sharp 提交于
      A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit
      transition fails.  The current code in hub_events simply issues a warm
      reset, but does not call any pre-reset or post-reset driver methods (or
      unbind/rebind drivers without them).  Therefore the drivers won't know
      their device has just been reset.
      
      hub_events should instead call usb_reset_device.  This means
      hub_port_reset now needs to figure out whether it should issue a warm
      reset or a hot reset.
      
      Remove the FIXME note about needing disconnect() for a NOTATTACHED
      device.  This patch fixes that.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      d3b9d7a9
    • S
      USB: Rip out recursive call on warm port reset. · a24a6078
      Sarah Sharp 提交于
      When a hot reset fails on a USB 3.0 port, the current port reset code
      recursively calls hub_port_reset inside hub_port_wait_reset.  This isn't
      ideal, since we should avoid recursive calls in the kernel, and it also
      doesn't allow us to issue multiple warm resets on reset failures.
      
      Rip out the recursive call.  Instead, add code to hub_port_reset to
      issue a warm reset if the hot reset fails, and try multiple warm resets
      before giving up on the port.
      
      In hub_port_wait_reset, remove the recursive call and re-indent.  The
      code is basically the same, except:
      
      1. It bails out early if the port has transitioned to Inactive or
      Compliance Mode after the reset completed.
      
      2. It doesn't consider a connect status change to be a failed reset.  If
      multiple warm resets needed to be issued, the connect status may have
      changed, so we need to ignore that and look at the port link state
      instead.  hub_port_reset will now do that.
      
      3. It unconditionally sets udev->speed on all types of successful
      resets.  The old recursive code would set the port speed when the second
      hub_port_reset returned.
      
      The old code did not handle connected devices needing a warm reset well.
      There were only two situations that the old code handled correctly: an
      empty port needing a warm reset, and a hot reset that migrated to a warm
      reset.
      
      When an empty port needed a warm reset, hub_port_reset was called with
      the warm variable set.  The code in hub_port_finish_reset would skip
      telling the USB core and the xHC host that the device was reset, because
      otherwise that would result in a NULL pointer dereference.
      
      When a USB 3.0 device reset migrated to a warm reset, the recursive call
      made the call stack look like this:
      
      hub_port_reset(warm = false)
              hub_wait_port_reset(warm = false)
                      hub_port_reset(warm = true)
                              hub_wait_port_reset(warm = true)
                              hub_port_finish_reset(warm = true)
                              (return up the call stack to the first wait)
      
              hub_port_finish_reset(warm = false)
      
      The old code didn't want to notify the USB core or the xHC host of device reset
      twice, so it only did it in the second call to hub_port_finish_reset,
      when warm was set to false.  This was necessary because
      before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
      would pay attention to the xHC Reset Device command error status, and
      the second call would always fail.
      
      Now that we no longer have the recursive call, and warm can change from
      false to true in hub_port_reset, we need to have hub_port_finish_reset
      unconditionally notify the USB core and the xHC of the device reset.
      
      In hub_port_finish_reset, unconditionally clear the connect status
      change (CSC) bit for USB 3.0 hubs when the port reset is done.  If we
      had to issue multiple warm resets for a device, that bit may have been
      set if the device went into SS.Inactive and then was successfully warm
      reset.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      a24a6078
    • S
      USB: Prepare for refactoring by adding extra udev checks. · 2d4fa940
      Sarah Sharp 提交于
      The next patch will refactor the hub port code to rip out the recursive
      call to hub_port_reset on a failed hot reset.  In preparation for that,
      make sure all code paths can deal with being called with a NULL udev.
      The usb_device will not be valid if warm reset was issued because a port
      transitioned to the Inactive or Compliance Mode on a device connect.
      
      This patch should have no effect on current behavior.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      2d4fa940
    • S
      USB: Don't use EHCI port sempahore for USB 3.0 hubs. · 0fe51aa5
      Sarah Sharp 提交于
      The EHCI host controller needs to prevent EHCI initialization when the
      UHCI or OHCI companion controller is in the middle of a port reset.  It
      uses ehci_cf_port_reset_rwsem to do this.  USB 3.0 hubs can't be under
      an EHCI host controller, so it makes no sense to down the semaphore for
      USB 3.0 hubs.  It also makes the warm port reset code more complex.
      
      Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      0fe51aa5
    • S
      USB: Handle warm reset failure on empty port. · 65bdac5e
      Sarah Sharp 提交于
      An empty port can transition to either Inactive or Compliance Mode if a
      newly connected USB 3.0 device fails to link train.  In that case, we
      issue a warm reset.  Some devices, such as John's Roseweil eusb3
      enclosure, slip back into Compliance Mode after the warm reset.
      
      The current warm reset code does not check for device connect status on
      warm reset completion, and it incorrectly reports the warm reset
      succeeded.  This causes the USB core to attempt to send a Set Address
      control transfer to a port in Compliance Mode, which will always fail.
      
      Make hub_port_wait_reset check the current connect status and link state
      after the warm reset completes.  Return a failure status if the device
      is disconnected or the link state is Compliance Mode or SS.Inactive.
      
      Make hub_events disable the port if warm reset fails.  This will disable
      the port, and then bring it back into the RxDetect state.  Make the USB
      core ignore the connect change until the device reconnects.
      
      Note that this patch does NOT handle connected devices slipping into the
      Inactive state very well.  This is a concern, because devices can go
      into the Inactive state on U1/U2 exit failure.  However, the fix for
      that case is too large for stable, so it will be submitted in a separate
      patch.
      
      This patch should be backported to kernels as old as 3.2, contain the
      commit ID 75d7cf72 "usbcore: refine warm
      reset logic"
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NJohn Covici <covici@ccs.covici.com>
      Cc: stable@vger.kernel.org
      65bdac5e
    • S
      USB: Ignore port state until reset completes. · 4f43447e
      Sarah Sharp 提交于
      The port reset code bails out early if the current connect status is
      cleared (device disconnected).  If we're issuing a hot reset, it may
      also look at the link state before the reset is finished.
      
      Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the
      Error state or Resetting state, the port connection bit retains the
      value from the previous state.  Therefore we can't trust it until the
      reset finishes.  Also, the xHCI spec section 4.19.1.2.5 says software
      shall ignore the link state while the port is resetting, as it can be in
      an unknown state.
      
      The port state during reset is also unknown for USB 2.0 hubs.  The hub
      sends a reset signal by driving the bus into an SE0 state.  This
      overwhelms the "connect" signal from the device, so the port can't tell
      whether anything is connected or not.
      
      Fix the port reset code to ignore the port link state and current
      connect bit until the reset finishes, and USB_PORT_STAT_RESET is
      cleared.
      
      Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case,
      because it's redundant.  When the warm reset finishes, the port reset
      bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set.
      Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit
      in the code to deal with the finished reset.
      
      This patch should be backported to all stable kernels.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable@vger.kernel.org
      4f43447e
    • S
      USB: Increase reset timeout. · 77c7f072
      Sarah Sharp 提交于
      John's NEC 0.96 xHCI host controller needs a longer timeout for a warm
      reset to complete.  The logs show it takes 650ms to complete the warm
      reset, so extend the hub reset timeout to 800ms to be on the safe side.
      
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NJohn Covici <covici@ccs.covici.com>
      Cc: stable@vger.kernel.org
      77c7f072
    • S
      USB: Allow USB 3.0 ports to be disabled. · 41e7e056
      Sarah Sharp 提交于
      If hot and warm reset fails, or a port remains in the Compliance Mode,
      the USB core needs to be able to disable a USB 3.0 port.  Unlike USB 2.0
      ports, once the port is placed into the Disabled link state, it will not
      report any new device connects.  To get device connect notifications, we
      need to put the link into the Disabled state, and then the RxDetect
      state.
      
      The xHCI driver needs to atomically clear all change bits on USB 3.0
      port disable, so that we get Port Status Change Events for future port
      changes.  We could technically do this in the USB core instead of in the
      xHCI roothub code, since the port state machine can't advance out of the
      disabled state until we set the link state to RxDetect.  However,
      external USB 3.0 hubs don't need this code.  They are level-triggered,
      not edge-triggered like xHCI, so they will continue to send interrupt
      events when any change bit is set.  Therefore it doesn't make sense to
      put this code in the USB core.
      
      This patch is part of a series to fix several reports of infinite loops
      on device enumeration failure.  This includes John, when he boots with
      a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
      host controller.  The fix requires warm reset support, so it does not
      make sense to backport this patch to stable kernels without warm reset
      support.
      
      This patch should be backported to kernels as old as 3.2, contain the
      commit ID 75d7cf72 "usbcore: refine warm
      reset logic"
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NJohn Covici <covici@ccs.covici.com>
      Cc: stable@vger.kernel.org
      41e7e056
    • S
      USB: Ignore xHCI Reset Device status. · 8b8132bc
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable@vger.kernel.org
      8b8132bc
    • S
      USB: Handle auto-transition from hot to warm reset. · 1c7439c6
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable@vger.kernel.org
      1c7439c6
  15. 22 11月, 2012 2 次提交
  16. 19 11月, 2012 1 次提交
  17. 16 11月, 2012 1 次提交