1. 28 9月, 2011 1 次提交
  2. 20 8月, 2011 1 次提交
  3. 02 8月, 2011 1 次提交
  4. 08 7月, 2011 1 次提交
  5. 02 7月, 2011 1 次提交
  6. 22 6月, 2011 1 次提交
  7. 16 6月, 2011 3 次提交
    • A
      USB: don't let errors prevent system sleep · 0af212ba
      Alan Stern 提交于
      This patch (as1464) implements the recommended policy that most errors
      during suspend or hibernation should not prevent the system from going
      to sleep.  In particular, failure to suspend a USB driver or a USB
      device should not prevent the sleep from succeeding:
      
      Failure to suspend a device won't matter, because the device will
      automatically go into suspend mode when the USB bus stops carrying
      packets.  (This might be less true for USB-3.0 devices, but let's not
      worry about them now.)
      
      Failure of a driver to suspend might lead to trouble later on when the
      system wakes up, but it isn't sufficient reason to prevent the system
      from going to sleep.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0af212ba
    • A
      USB: don't let the hub driver prevent system sleep · cbb33004
      Alan Stern 提交于
      This patch (as1465) continues implementation of the policy that errors
      during suspend or hibernation should not prevent the system from going
      to sleep.
      
      In this case, failure to turn on the Suspend feature for a hub port
      shouldn't be reported as an error.  There are situations where this
      does actually occur (such as when the device plugged into that port
      was disconnected in the recent past), and it turns out to be harmless.
      There's no reason for it to prevent a system sleep.
      
      Also, don't allow the hub driver to fail a system suspend if the
      downstream ports aren't all suspended.  This is also harmless (and
      should never happen, given the change mentioned above); printing a
      warning message in the kernel log is all we really need to do.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      cbb33004
    • S
      USB: Free bandwidth when usb_disable_device is called. · fccf4e86
      Sarah Sharp 提交于
      Tanya ran into an issue when trying to switch a UAS device from the BOT
      configuration to the UAS configuration via the bConfigurationValue sysfs
      file.  Before installing the UAS configuration, set_bConfigurationValue()
      calls usb_disable_device().  That function is supposed to remove all host
      controller resources associated with that device, but it leaves some state
      in the xHCI host controller.
      
      Commit 0791971b
      	usb: allow drivers to use allocated bandwidth until unbound
      added a call to usb_disable_device() in usb_set_configuration(), before
      the xHCI bandwidth functions were invoked.  That commit fixed a bug, but
      also introduced a bug that is triggered when a configured device is
      switched to a new configuration.
      
      usb_disable_device() goes through all the motions of unbinding the drivers
      attached to active interfaces and removing the USB core structures
      associated with those interfaces, but it doesn't actually remove the
      endpoints from the internal xHCI host controller bandwidth structures.
      
      When usb_disable_device() calls usb_disable_endpoint() with reset_hardware
      set to true, the entries in udev->ep_out and udev->ep_in will be set to
      NULL.  Usually, when the USB core installs a new configuration,
      usb_hcd_alloc_bandwidth() will drop all non-NULL endpoints in udev->ep_out
      and udev->ep_in before adding any new endpoints.  However, when the new
      UAS configuration was added, all those entries were null, so none of the
      old endpoints in the BOT configuration were dropped.
      
      The xHCI driver blindly added the UAS configuration endpoints, and some of
      the endpoint addresses overlapped with the old BOT configuration
      endpoints.  This caused the xHCI host to reject the Configure Endpoint
      command.  Now that the xHCI driver code is cleaned up to reject a
      double-add of active endpoints, we need to fix the USB core to properly
      drop old endpoints in usb_disable_device().
      
      If the host controller driver needs bandwidth checking support, make
      usb_disable_device() call usb_disable_endpoint() with
      reset_hardware set to false, drop the endpoints from the xHCI host
      controller, and then call usb_disable_endpoint() again with
      reset_hardware set to true.
      
      The first call to usb_disable_endpoint() will cancel any pending URBs and
      wait on them to be freed in usb_hcd_disable_endpoint(), but will keep the
      pointers in udev->ep_out and udev->ep in intact.  Then
      usb_hcd_alloc_bandwidth() will use those pointers to know which endpoints
      to drop.
      
      The final call to usb_disable_endpoint() will do two things:
      
      1. It will call usb_hcd_disable_endpoint() again, which should be harmless
      since the ep->urb_list should be empty after the first call to
      usb_disable_endpoint() returns.
      
      2. It will set the entries in udev->ep_out and udev->ep in to NULL, and call
      usb_hcd_disable_endpoint().  That call will have no effect, since the xHCI
      driver doesn't set the endpoint_disable function pointer.
      
      Note that usb_disable_device() will now need to be called with
      hcd->bandwidth_mutex held.
      
      This should be backported to kernels as old as 2.6.32.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NTanya Brokhman <tlinder@codeaurora.org>
      Cc: ablay@codeaurora.org
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: stable@kernel.org
      fccf4e86
  8. 07 6月, 2011 3 次提交
  9. 04 6月, 2011 1 次提交
  10. 20 5月, 2011 1 次提交
    • A
      USB: remove remaining usages of hcd->state from usbcore and fix regression · 69fff59d
      Alan Stern 提交于
      This patch (as1467) removes the last usages of hcd->state from
      usbcore.  We no longer check to see if an interrupt handler finds that
      a controller has died; instead we rely on host controller drivers to
      make an explicit call to usb_hc_died().
      
      This fixes a regression introduced by commit
      9b37596a (USB: move usbcore away from
      hcd->state).  It used to be that when a controller shared an IRQ with
      another device and an interrupt arrived while hcd->state was set to
      HC_STATE_HALT, the interrupt handler would be skipped.  The commit
      removed that test; as a result the current code doesn't skip calling
      the handler and ends up believing the controller has died, even though
      it's only temporarily stopped.  The solution is to ignore HC_STATE_HALT
      following the handler's return.
      
      As a consequence of this change, several of the host controller
      drivers need to be modified.  They can no longer implicitly rely on
      usbcore realizing that a controller has died because of hcd->state.
      The patch adds calls to usb_hc_died() in the appropriate places.
      
      The patch also changes a few of the interrupt handlers.  They don't
      expect to be called when hcd->state is equal to HC_STATE_HALT, even if
      the controller is still alive.  Early returns were added to avoid any
      confusion.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NManuel Lauss <manuel.lauss@googlemail.com>
      CC: Rodolfo Giometti <giometti@linux.it>
      CC: Olav Kongas <ok@artecdesign.ee>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      69fff59d
  11. 03 5月, 2011 4 次提交
  12. 30 4月, 2011 2 次提交
  13. 14 4月, 2011 5 次提交
  14. 31 3月, 2011 1 次提交
  15. 24 3月, 2011 1 次提交
  16. 19 3月, 2011 1 次提交
  17. 15 3月, 2011 2 次提交
  18. 14 3月, 2011 10 次提交
    • P
      USB: Add support for SuperSpeed isoc endpoints · 500132a0
      Paul Zimmerman 提交于
      Use the Mult and bMaxBurst values from the endpoint companion
      descriptor to calculate the max length of an isoc transfer.
      
      Add USB_SS_MULT macro to access Mult field of bmAttributes, at
      Sarah's suggestion.
      
      This patch should be queued for the 2.6.36 and 2.6.37 stable trees, since
      those were the first kernels to have isochronous support for SuperSpeed
      devices.
      Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      500132a0
    • S
      USB: Disable auto-suspend for USB 3.0 hubs. · 0c9ffe0f
      Sarah Sharp 提交于
      USB 3.0 devices have a slightly different suspend sequence than USB
      2.0/1.1 devices.  There isn't support for USB 3.0 device suspend yet, so
      make khubd leave autosuspend disabled for USB 3.0 hubs.  Make sure that
      USB 3.0 roothubs still have autosuspend enabled, since that path in the
      xHCI driver works fine.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      0c9ffe0f
    • S
      USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol. · 131dec34
      Sarah Sharp 提交于
      USB_PORT_STAT_SUPER_SPEED is a made up symbol that the USB core used to
      track whether USB ports had a SuperSpeed device attached.  This is a
      linux-internal symbol that was used when SuperSpeed and non-SuperSpeed
      devices would show up under the same xHCI roothub.  This particular
      port status is never returned by external USB 3.0 hubs.  (Instead they
      have a USB_PORT_STAT_SPEED_5GBPS that uses a completely different speed
      mask.)
      
      Now that the xHCI driver registers two roothubs, USB 3.0 devices will only
      show up under USB 3.0 hubs.  Rip out USB_PORT_STAT_SUPER_SPEED and replace
      it with calls to hub_is_superspeed().
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      131dec34
    • S
      USB: Set usb_hcd->state and flags for shared roothubs. · ff9d78b3
      Sarah Sharp 提交于
      The hcd->flags are in a sorry state.  Some of them are clearly specific to
      the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
      HCD_WAKEUP_PENDING), but some flags are related to PCI device state
      (HCD_HW_ACCESSIBLE and HCD_SAW_IRQ).  This is an issue when one PCI device
      can have two roothubs that share the same IRQ line and hardware.
      
      Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
      serviced, or an URB is unlinked without an interrupt.  (We can't tell if
      the host actually serviced an interrupt for a particular bus, but we can
      tell it serviced some interrupt.)
      
      HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
      roothubs as they are added, so it doesn't need to be modified.
      HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
      they are never set by the xHCI driver, since the roothub never needs to be
      polled.
      
      The usb_hcd's state field is a similar mess.  Sometimes the state applies
      to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
      HC_STATE_QUIESCING.  But sometimes the state refers to the roothub state:
      HC_STATE_RESUMING and HC_STATE_SUSPENDED.
      
      Alan Stern recently made the USB core not rely on the hcd->state variable.
      Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
      that code in.  Remove all references to HC_STATE_HALT, since the xHCI
      driver only sets and doesn't test those variables.  We still have to set
      HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
      won't get registered if we don't set that.
      
      Alan's patch made the USB core check a different variable when trying to
      determine whether to suspend a roothub.  The xHCI host has a split
      roothub, where two buses are registered for one PCI device.  Each bus in
      the xHCI split roothub can be suspended separately, but both buses must be
      suspended before the PCI device can be suspended.  Therefore, make sure
      that the USB core checks HCD_RH_RUNNING() for both roothubs before
      suspending the PCI host.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      ff9d78b3
    • S
      usb: Make core allocate resources per PCI-device. · c5635437
      Sarah Sharp 提交于
      Introduce the notion of a PCI device that may be associated with more than
      one USB host controller driver (struct usb_hcd).  This patch is the start
      of the work to separate the xHCI host controller into two roothubs: a USB
      3.0 roothub with SuperSpeed-only ports, and a USB 2.0 roothub with
      HS/FS/LS ports.
      
      One usb_hcd structure is designated to be the "primary HCD", and a pointer
      is added to the usb_hcd structure to keep track of that.  A new function
      call, usb_hcd_is_primary_hcd() is added to check whether the USB hcd is
      marked as the primary HCD (or if it is not part of a roothub pair).  To
      allow the USB core and xHCI driver to access either roothub in a pair, a
      "shared_hcd" pointer is added to the usb_hcd structure.
      
      Add a new function, usb_create_shared_hcd(), that does roothub allocation
      for paired roothubs.  It will act just like usb_create_hcd() did if the
      primary_hcd pointer argument is NULL.  If it is passed a non-NULL
      primary_hcd pointer, it sets usb_hcd->shared_hcd and usb_hcd->primary_hcd
      fields.  It will also skip the bandwidth_mutex allocation, and set the
      secondary hcd's bandwidth_mutex pointer to the primary HCD's mutex.
      
      IRQs are only allocated once for the primary roothub.
      
      Introduce a new usb_hcd driver flag that indicates the host controller
      driver wants to create two roothubs.  If the HCD_SHARED flag is set, then
      the USB core PCI probe methods will allocate a second roothub, and make
      sure that second roothub gets freed during rmmod and in initialization
      error paths.
      
      When usb_hc_died() is called with the primary HCD, make sure that any
      roothubs that share that host controller are also marked as being dead.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c5635437
    • S
      usb: Store bus type in usb_hcd, not in driver flags. · 83de4b2b
      Sarah Sharp 提交于
      The xHCI driver essentially has both a USB 2.0 and a USB 3.0 roothub.  So
      setting the HCD_USB3 bits in the hcd->driver->flags is a bit misleading.
      Add a new field to usb_hcd, bcdUSB.  Store the result of
      hcd->driver->flags & HCD_MASK in it.  Later, when we have the xHCI driver
      register the two roothubs, we'll set the usb_hcd->bcdUSB field to HCD_USB2
      for the USB 2.0 roothub, and HCD_USB3 for the USB 3.0 roothub.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      83de4b2b
    • S
      usb: Change usb_hcd->bandwidth_mutex to a pointer. · d673bfcb
      Sarah Sharp 提交于
      Change the bandwith_mutex in struct usb_hcd to a pointer.  This will allow
      the pointer to be shared across usb_hcds for the upcoming work to split
      the xHCI driver roothub into a USB 2.0/1.1 and a USB 3.0 bus.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d673bfcb
    • S
      usb: Refactor irq enabling out of usb_add_hcd() · 23e0d106
      Sarah Sharp 提交于
      Refactor out the code in usb_add_hcd() to request the IRQ line for the
      HCD.  This will only need to be called once for the two xHCI roothubs, so
      it's easier to refactor it into a function, rather than wrapping the long
      if-else block into another if statement.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      23e0d106
    • S
      usb: Make usb_hcd_pci_probe labels more descriptive. · 8766c815
      Sarah Sharp 提交于
      Make the labels for the goto statements in usb_hcd_pci_probe()
      describe the cleanup they do, rather than being numbered err[1-4].
      This makes it easier to add error handling later.
      
      The error handling for this function looks a little fishy, since
      set_hs_companion() isn't called until the very end of the function, and
      clear_hs_companion() is called if this function fails earlier than that.
      But it should be harmless to clear a NULL pointer, so leave the error
      handling as-is.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      8766c815
    • S
      usb: Make USB 3.0 roothub have a SS EP comp descriptor. · 22c6a35d
      Sarah Sharp 提交于
      Make the USB 3.0 roothub registered by the USB core have a SuperSpeed
      Endpoint Companion Descriptor after the interrupt endpoint.  All USB 3.0
      devices are required to have this, and the USB 3.0 bus specification
      (section 10.13.1) says which values the descriptor should have.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      22c6a35d
新手
引导
客服 返回
顶部