1. 04 1月, 2013 8 次提交
    • S
      xhci: Avoid "dead ports", add roothub port polling. · c52804a4
      Sarah Sharp 提交于
      The USB core hub thread (khubd) is designed with external USB hubs in
      mind.  It expects that if a port status change bit is set, the hub will
      continue to send a notification through the hub status data transfer.
      Basically, it expects hub notifications to be level-triggered.
      
      The xHCI host controller is designed to be edge-triggered on the logical
      'OR' of all the port status change bits.  When all port status change
      bits are clear, and a new change bit is set, the xHC will generate a
      Port Status Change Event.  If another change bit is set in the same port
      status register before the first bit is cleared, it will not send
      another event.
      
      This means that the hub code may lose port status changes because of
      race conditions between clearing change bits.  The user sees this as a
      "dead port" that doesn't react to device connects.
      
      The fix is to turn on port polling whenever a new change bit is set.
      Once the USB core issues a hub status request that shows that no change
      bits are set in any USB ports, turn off port polling.
      
      We can't allow the USB core to poll the roothub for port events during
      host suspend because if the PCI host is in D3cold, the port registers
      will be all f's.  Instead, stop the port polling timer, and
      unconditionally restart it when the host resumes.  If there are no port
      change bits set after the resume, the first call to hub_status_data will
      disable polling.
      
      This patch should be backported to stable kernels with the first xHCI
      support, 2.6.31 and newer, that include the commit
      0f2a7930 "USB: xhci: Root hub support."
      There will be merge conflicts because the check for HC_STATE_SUSPENDED
      was moved into xhci_suspend in 3.8.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable@vger.kernel.org
      c52804a4
    • 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
    • S
      xhci: Handle HS bulk/ctrl endpoints that don't NAK. · 55c1945e
      Sarah Sharp 提交于
      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: NVincent Pelletier <plr.vincent@gmail.com>
      Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      55c1945e
  2. 22 12月, 2012 32 次提交