1. 29 9月, 2014 2 次提交
  2. 24 9月, 2014 1 次提交
  3. 05 3月, 2014 1 次提交
  4. 11 12月, 2013 1 次提交
    • D
      usb: xhci: change enumeration scheme to 'new scheme' by default · 48fc7dbd
      Dan Williams 提交于
      Change the default enumeration scheme for xhci attached non-SuperSpeed
      devices from:
      
         Reset
         SetAddress [xhci address-device BSR = 0]
         GetDescriptor(8)
         GetDescriptor(18)
      
      ...to:
      
         Reset
         [xhci address-device BSR = 1]
         GetDescriptor(64)
         Reset
         SetAddress [xhci address-device BSR = 0]
         GetDescriptor(18)
      
      ...as some devices misbehave when encountering a SetAddress command
      prior to GetDescriptor.  There are known legacy devices that require
      this scheme, but testing has found at least one USB3 device that fails
      enumeration when presented with this ordering.  For now, follow the ehci
      case and enable 'new scheme' by default for non-SuperSpeed devices.
      
      To support this enumeration scheme on xhci the AddressDevice operation
      needs to be performed twice.  The first instance of the command enables
      the HC's device and slot context info for the device, but omits sending
      the device a SetAddress command (BSR == block set address request).
      Then, after GetDescriptor completes, follow up with the full
      AddressDevice+SetAddress operation.
      
      As mentioned before, this ordering of events with USB3 devices causes an
      extra state transition to be exposed to xhci.  Previously USB3 devices
      would transition directly from 'enabled' to 'addressed' and never need
      to underrun responses to 'get descriptor'. We do see the 64-byte
      descriptor fetch the correct data, but the following 18-byte descriptor
      read after the reset gets:
      
      bLength            = 0
      bDescriptorType    = 0
      bcdUSB             = 0
      bDeviceClass       = 0
      bDeviceSubClass    = 0
      bDeviceProtocol    = 0
      bMaxPacketSize0    = 9
      
      instead of:
      
      bLength            = 12
      bDescriptorType    = 1
      bcdUSB             = 300
      bDeviceClass       = 0
      bDeviceSubClass    = 0
      bDeviceProtocol    = 0
      bMaxPacketSize0    = 9
      
      which results in the discovery process looping until falling back to
      'old scheme' enumeration.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NDavid Moore <david.moore@gmail.com>
      Suggested-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      48fc7dbd
  5. 09 12月, 2013 1 次提交
  6. 12 10月, 2013 2 次提交
  7. 26 9月, 2013 1 次提交
    • H
      usb: core: implement AMD remote wakeup quirk · 7868943d
      Huang Rui 提交于
      The following patch is required to resolve remote wake issues with
      certain devices.
      
      Issue description:
      If the remote wake is issued from the device in a specific timing
      condition while the system is entering sleep state then it may cause
      system to auto wake on subsequent sleep cycle.
      
      Root cause:
      Host controller rebroadcasts the Resume signal > 100 µseconds after
      receiving the original resume event from the device. For proper
      function, some devices may require the rebroadcast of resume event
      within the USB spec of 100µS.
      
      Workaroud:
      1. Filter the AMD platforms with Yangtze chipset, then judge of all the usb
      devices are mouse or not. And get out the port id which attached a mouse
      with Pixart controller.
      2. Then reset the port which attached issue device during system resume
      from S3.
      
      [Q] Why the special devices are only mice? Would high speed devices
      such as 3G modem or USB Bluetooth adapter trigger this issue?
      - Current this sensitivity is only confined to devices that use Pixart
        controllers. This controller is designed for use with LS mouse
      devices only. We have not observed any other devices failing. There
      may be a small risk for other devices also but this patch (reset
      device in resume phase) will cover the cases if required.
      
      [Q] Shouldn’t the resume signal be sent within 100 us for every
      device?
      - The Host controller may not send the resume signal within 100us,
        this our host controller specification change. This is why we
      require the patch to prevent side effects on certain known devices.
      
      [Q] Why would clicking mouse INTENSELY to wake the system up trigger
      this issue?
      - This behavior is specific to the devices that use Pixart controller.
        It is timing dependent on when the resume event is triggered during
      the sleep state.
      
      [Q] Is it a host controller issue or mouse?
      - It is the host controller behavior during resume that triggers the
        device incorrect behavior on the next resume.
      
      This patch sets USB_QUIRK_RESET_RESUME flag for these Pixart-based mice
      when they attached to platforms with AMD Yangtze chipset.
      Signed-off-by: NHuang Rui <ray.huang@amd.com>
      Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7868943d
  8. 18 9月, 2013 1 次提交
    • A
      USB: see if URB comes from a completion handler · c7ccde6e
      Alan Stern 提交于
      Now that URBs can be completed inside tasklets, we need a way of
      determining whether a completion handler for a given endpoint is
      currently running.  Otherwise it's not possible to maintain the API
      guarantee about keeping isochronous streams synchronous when an
      underrun occurs.
      
      This patch adds a field and a routine to check whether a completion
      handler for a periodic endpoint is running.  At the moment no
      analogous routine appears to be necessary for async endpoints, but one
      can always be added.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Ming Lei <tom.leiming@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7ccde6e
  9. 31 8月, 2013 1 次提交
  10. 13 8月, 2013 1 次提交
    • M
      USB: HCD: support giveback of URB in tasklet context · 94dfd7ed
      Ming Lei 提交于
      This patch implements the mechanism of giveback of URB in
      tasklet context, so that hardware interrupt handling time for
      usb host controller can be saved much, and HCD interrupt handling
      can be simplified.
      
      Motivations:
      
      1), on some arch(such as ARM), DMA mapping/unmapping is a bit
      time-consuming, for example: when accessing usb mass storage
      via EHCI on pandaboard, the common length of transfer buffer is 120KB,
      the time consumed on DMA unmapping may reach hundreds of microseconds;
      even on A15 based box, the time is still about scores of microseconds
      
      2), on some arch, reading DMA coherent memoery is very time-consuming,
      the most common example is usb video class driver[1]
      
      3), driver's complete() callback may do much things which is driver
      specific, so the time is consumed unnecessarily in hardware irq context.
      
      4), running driver's complete() callback in hardware irq context causes
      that host controller driver has to release its lock in interrupt handler,
      so reacquiring the lock after return may busy wait a while and increase
      interrupt handling time. More seriously, releasing the HCD lock makes
      HCD becoming quite complicated to deal with introduced races.
      
      So the patch proposes to run giveback of URB in tasklet context, then
      time consumed in HCD irq handling doesn't depend on drivers' complete and
      DMA mapping/unmapping any more, also we can simplify HCD since the HCD
      lock isn't needed to be released during irq handling.
      
      The patch should be reasonable and doable:
      
      1), for drivers, they don't care if the complete() is called in hard irq
      context or softirq context
      
      2), the biggest change is the situation in which usb_submit_urb() is called
      in complete() callback, so the introduced tasklet schedule delay might be a
      con, but it shouldn't be a big deal:
      
      	- control/bulk asynchronous transfer isn't sensitive to schedule
      	  delay
      
      	- the patch schedules giveback of periodic URBs using
      	  tasklet_hi_schedule, so the introduced delay should be very
      	  small
      
      	- for ISOC transfer, generally, drivers submit several URBs
      	  concurrently to avoid interrupt delay, so it is OK with the
      	  little schedule delay.
      
      	- for interrupt transfer, generally, drivers only submit one URB
      	  at the same time, but interrupt transfer is often used in event
      	  report, polling, ... situations, and a little delay should be OK.
      
      Considered that HCDs may optimize on submitting URB in complete(), the
      patch may cause the optimization not working, so introduces one flag to mark
      if the HCD supports to run giveback URB in tasklet context. When all HCDs
      are ready, the flag can be removed.
      
      [1], http://marc.info/?t=136438111600010&r=1&w=2
      
      Cc: Oliver Neukum <oliver@neukum.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94dfd7ed
  11. 04 6月, 2013 1 次提交
  12. 29 3月, 2013 1 次提交
    • A
      USB: remove CONFIG_USB_SUSPEND option · 84ebc102
      Alan Stern 提交于
      This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially
      replacing it everywhere with CONFIG_PM_RUNTIME (except for one place
      in hub.c, where it is replaced with CONFIG_PM because the code needs
      to be used in both runtime and system PM).  The net result is code
      shrinkage and simplification.
      
      There's very little point in keeping CONFIG_USB_SUSPEND because almost
      everybody enables it.  The few that don't will find that the usbcore
      module has gotten somewhat bigger and they will have to take active
      measures if they want to prevent hubs from being runtime suspended.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Peter Chen <peter.chen@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84ebc102
  13. 26 3月, 2013 1 次提交
    • L
      usb: add find_raw_port_number callback to struct hc_driver() · 3f5eb141
      Lan Tianyu 提交于
      xhci driver divides the root hub into two logical hubs which work
      respectively for usb 2.0 and usb 3.0 devices. They are independent
      devices in the usb core. But in the ACPI table, it's one device node
      and all usb2.0 and usb3.0 ports are under it. Binding usb port with
      its acpi node needs the raw port number which is reflected in the xhci
      extended capabilities table. This patch is to add find_raw_port_number
      callback to struct hc_driver(), fill it with xhci_find_raw_port_number()
      which will return raw port number and add a wrap usb_hcd_find_raw_port_number().
      
      Otherwise, refactor xhci_find_real_port_number(). Using
      xhci_find_raw_port_number() to get real index in the HW port status
      registers instead of scanning through the xHCI roothub port array.
      This can help to speed up.
      
      All addresses in xhci->usb2_ports and xhci->usb3_ports array are
      kown good ports and don't include following bad ports in the extended
      capabilities talbe.
           (1) root port that doesn't have an entry
           (2) root port with unknown speed
           (3) root port that is listed twice and with different speeds.
      
      So xhci_find_raw_port_number() will only return port num of good ones
      and never touch bad ports above.
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      3f5eb141
  14. 26 1月, 2013 1 次提交
    • A
      USB: add usb_hcd_{start,end}_port_resume · da0aa716
      Alan Stern 提交于
      This patch (as1649) adds a mechanism for host controller drivers to
      inform usbcore when they have begun or ended resume signalling on a
      particular root-hub port.  The core will then make sure that the root
      hub does not get runtime-suspended while the port resume is going on.
      
      Since commit 596d789a (USB: set hub's
      default autosuspend delay as 0), the system tries to suspend hubs
      whenever they aren't in use.  While a root-hub port is being resumed,
      the root hub does not appear to be in use.  Attempted runtime suspends
      fail because of the ongoing port resume, but the PM core just keeps on
      trying over and over again.  We want to prevent this wasteful effort.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da0aa716
  15. 17 8月, 2012 1 次提交
  16. 14 6月, 2012 2 次提交
  17. 19 5月, 2012 1 次提交
    • S
      USB: Add support to enable/disable USB3 link states. · 1ea7e0e8
      Sarah Sharp 提交于
      There are various functions within the USB core that will need to
      disable USB 3.0 link power states.  For example, when a USB device
      driver is being bound to an interface, we need to disable USB 3.0 LPM
      until we know if the driver will allow hub-initiated LPM transitions.
      Another example is when the USB core is switching alternate interface
      settings.  The USB 3.0 timeout values are dependent on what endpoints
      are enabled, so we want to ensure that LPM is disabled until the new alt
      setting is fully installed.
      
      Multiple functions need to disable LPM, and those functions can even be
      nested.  For example, usb_bind_interface() could disable LPM, and then
      call into the driver probe function, which may attempt to switch to a
      different alt setting.  Therefore, we need to keep a count of the number
      of functions that require LPM to be disabled at any point in time.
      
      Introduce two new USB core API calls, usb_disable_lpm() and
      usb_enable_lpm().  These functions increment and decrement a new
      variable in the usb_device, lpm_disable_count.  If usb_disable_lpm()
      fails, it will call usb_enable_lpm() in order to balance the
      lpm_disable_count.
      
      These two new functions must be called with the bandwidth_mutex locked.
      If the bandwidth_mutex is not already held by the caller, it should
      instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take
      the bandwidth_mutex before calling usb_disable_lpm() and
      usb_enable_lpm(), respectively.
      
      Introduce a new variable (timeout) in the usb3_lpm_params structure to
      keep track of the currently enabled U1/U2 timeout values.  When
      usb_disable_lpm() is called, and the USB device has the U1 or U2
      timeouts set to a non-zero value (meaning either device-initiated or
      hub-initiated LPM is enabled), attempt to disable LPM, regardless of the
      state of the lpm_disable_count.  We want to ensure that all callers can
      be guaranteed that LPM is disabled if usb_disable_lpm() returns zero.
      
      Otherwise the following scenario could occur:
      
      1. Driver A is being bound to interface 1.  usb_probe_interface()
      disables LPM.  Driver A doesn't care if hub-initiated LPM is enabled, so
      even though usb_disable_lpm() fails, the probe of the driver continues,
      and the bandwidth mutex is dropped.
      
      2. Meanwhile, Driver B is being bound to interface 2.
      usb_probe_interface() grabs the bandwidth mutex and calls
      usb_disable_lpm().  That call should attempt to disable LPM, even
      though the lpm_disable_count is set to 1 by Driver A.
      
      For usb_enable_lpm(), we attempt to enable LPM only when the
      lpm_disable_count is zero.  If some step in enabling LPM fails, it will
      only have a minimal impact on power consumption, and all USB device
      drivers should still work properly.  Therefore don't bother to return
      any error codes.
      
      Don't enable device-initiated LPM if the device is unconfigured.  The
      USB device will only accept the U1/U2_ENABLE control transfers in the
      configured state.  Do enable hub-initiated LPM in that case, since
      devices are allowed to accept the LGO_Ux link commands in any state.
      
      Don't enable or disable LPM if the device is marked as not being LPM
      capable.  This can happen if:
       - the USB device doesn't have a SS BOS descriptor,
       - the device's parent hub has a zeroed bHeaderDecodeLatency value, or
       - the xHCI host doesn't support LPM.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Andiry Xu <andiry.xu@amd.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      1ea7e0e8
  18. 30 4月, 2012 1 次提交
  19. 25 4月, 2012 1 次提交
    • A
      USB: EHCI: fix crash during suspend on ASUS computers · 151b6128
      Alan Stern 提交于
      This patch (as1545) fixes a problem affecting several ASUS computers:
      The machine crashes or corrupts memory when going into suspend if the
      ehci-hcd driver is bound to any controllers.  Users have been forced
      to unbind or unload ehci-hcd before putting their systems to sleep.
      
      After extensive testing, it was determined that the machines don't
      like going into suspend when any EHCI controllers are in the PCI D3
      power state.  Presumably this is a firmware bug, but there's nothing
      we can do about it except to avoid putting the controllers in D3
      during system sleep.
      
      The patch adds a new flag to indicate whether the problem is present,
      and avoids changing the controller's power state if the flag is set.
      Runtime suspend is unaffected; this matters only for system suspend.
      However as a side effect, the controller will not respond to remote
      wakeup requests while the system is asleep.  Hence USB wakeup is not
      functional -- but of course, this is already true in the current state
      of affairs.
      
      This fixes Bugzilla #42728.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Tested-by: NAndrey Rahmatullin <wrar@wrar.name>
      Tested-by: NOleksij Rempel (fishor) <bug-track@fisher-privat.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      151b6128
  20. 02 3月, 2012 1 次提交
  21. 15 2月, 2012 1 次提交
    • S
      USB/xHCI: Support device-initiated USB 3.0 resume. · 4ee823b8
      Sarah Sharp 提交于
      USB 3.0 hubs don't have a port suspend change bit (that bit is now
      reserved).  Instead, when a host-initiated resume finishes, the hub sets
      the port link state change bit.
      
      When a USB 3.0 device initiates remote wakeup, the parent hubs with
      their upstream links in U3 will pass the LFPS up the chain.  The first
      hub that has an upstream link in U0 (which may be the roothub) will
      reflect that LFPS back down the path to the device.
      
      However, the parent hubs in the resumed path will not set their link
      state change bit.  Instead, the device that initiated the resume has to
      send an asynchronous "Function Wake" Device Notification up to the host
      controller.  Therefore, we need a way to notify the USB core of a device
      resume without going through the normal hub URB completion method.
      
      First, make the xHCI roothub act like an external USB 3.0 hub and not
      pass up the port link state change bit when a device-initiated resume
      finishes.  Introduce a new xHCI bit field, port_remote_wakeup, so that
      we can tell the difference between a port coming out of the U3Exit state
      (host-initiated resume) and the RExit state (ending state of
      device-initiated resume).
      
      Since the USB core can't tell whether a port on a hub has resumed by
      looking at the Hub Status buffer, we need to introduce a bitfield,
      wakeup_bits, that indicates which ports have resumed.  When the xHCI
      driver notices a port finishing a device-initiated resume, we call into
      a new USB core function, usb_wakeup_notification(), that will set
      the right bit in wakeup_bits, and kick khubd for that hub.
      
      We also call usb_wakeup_notification() when the Function Wake Device
      Notification is received by the xHCI driver.  This covers the case where
      the link between the roothub and the first-tier hub is in U0, and the
      hub reflects the resume signaling back to the device without giving any
      indication it has done so until the device sends the Function Wake
      notification.
      
      Change the code in khubd that handles the remote wakeup to look at the
      state the USB core thinks the device is in, and handle the remote wakeup
      if the port's wakeup bit is set.
      
      This patch only takes care of the case where the device is attached
      directly to the roothub, or the USB 3.0 hub that is attached to the root
      hub is the device sending the Function Wake Device Notification (e.g.
      because a new USB device was attached).  The other cases will be covered
      in a second patch.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      4ee823b8
  22. 15 11月, 2011 1 次提交
    • A
      USB: Remove the SAW_IRQ hcd flag · 968b822c
      Alan Stern 提交于
      The HCD_FLAG_SAW_IRQ flag was introduced in order to catch IRQ routing
      errors: If an URB was unlinked and the host controller hadn't gotten
      any IRQs, it seemed likely that the IRQs were directed to the wrong
      vector.
      
      This warning hasn't come up in many years, as far as I know; interrupt
      routing now seems to be well under control.  Therefore there's no
      reason to keep the flag around any more.  This patch (as1495) finally
      removes it.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      968b822c
  23. 11 10月, 2011 1 次提交
  24. 27 9月, 2011 1 次提交
  25. 14 3月, 2011 4 次提交
    • 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: Remove bitmap #define from hcd.h · da13051c
      Sarah Sharp 提交于
      Using a #define to redefine a common variable name is a bad thing,
      especially when the #define is in a header.  include/linux/usb/hcd.h
      redefined bitmap to DeviceRemovable to avoid typing a long field in the
      hub descriptor.  This has unintended side effects for files like
      drivers/usb/core/devio.c that include that file, since another header
      included after hcd.h has different variables named bitmap.
      
      Remove the bitmap #define and replace instances of it in the host
      controller code.  Cleanup the spaces around function calls and square
      brackets while we're at it.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Cc: Tony Olech <tony.olech@elandigitalsystems.com>
      Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>
      Cc: Max Vozeler <mvz@vozeler.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Cc: Rodolfo Giometti <giometti@linux.it>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Anton Vorontsov <avorontsov@mvista.com>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Lothar Wassmann <LW@KARO-electronics.de>
      Cc: Olav Kongas <ok@artecdesign.ee>
      Cc: Martin Fuzzey <mfuzzey@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      da13051c
  26. 08 3月, 2011 1 次提交
    • A
      USB: move usbcore away from hcd->state · 9b37596a
      Alan Stern 提交于
      The hcd->state variable is a disaster.  It's not clearly owned by
      either usbcore or the host controller drivers, and they both change it
      from time to time, potentially stepping on each other's toes.  It's
      not protected by any locks.  And there's no mechanism to prevent it
      from going through an invalid transition.
      
      This patch (as1451) takes a first step toward fixing these problems.
      As it turns out, usbcore uses hcd->state for essentially only two
      things: checking whether the controller's root hub is running and
      checking whether the controller has died.  Therefore the patch adds
      two new atomic bitflags to the hcd structure, to store these pieces of
      information.  The new flags are used only by usbcore, and a private
      spinlock prevents invalid combinations (a dead controller's root hub
      cannot be running).
      
      The patch does not change the places where usbcore sets hcd->state,
      since HCDs may depend on them.  Furthermore, there is one place in
      usb_hcd_irq() where usbcore still must use hcd->state: An HCD's
      interrupt handler can implicitly indicate that the controller died by
      setting hcd->state to HC_STATE_HALT.  Nevertheless, the new code is a
      big improvement over the current code.
      
      The patch makes one other change.  The hcd_bus_suspend() and
      hcd_bus_resume() routines now check first whether the host controller
      has died; if it has then they return immediately without calling the
      HCD's bus_suspend or bus_resume methods.
      
      This fixes the major problem reported in Bugzilla #29902: The system
      fails to suspend after a host controller dies during system resume.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NAlex Terekhov <a.terekhov@gmail.com>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9b37596a
  27. 05 2月, 2011 2 次提交
  28. 15 1月, 2011 1 次提交
  29. 11 11月, 2010 1 次提交
  30. 23 10月, 2010 2 次提交
  31. 11 8月, 2010 2 次提交
    • A
      USB: fix race between root-hub wakeup & controller suspend · ff2f0787
      Alan Stern 提交于
      This patch (as1395) adds code to hcd_pci_suspend() for handling wakeup
      races.  This is another general race pattern, similar to the "open
      vs. unregister" race we're all familiar with.  Here, the race is
      between suspending a device and receiving a wakeup request from one of
      the device's suspended children.
      
      In particular, if a root-hub wakeup is requested at about the same
      time as the corresponding USB controller is suspended, and if the
      controller is enabled for wakeup, then the controller should either
      fail to suspend or else wake right back up again.
      
      During system sleep this won't happen very much, especially since host
      controllers generally aren't enabled for wakeup during sleep.  However
      it is definitely an issue for runtime PM.  Something like this will be
      needed to prevent the controller from autosuspending while waiting for
      a root-hub resume to take place.  (That is, in fact, the common case,
      for which there is an extra test.)
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ff2f0787
    • A
      USB: add do_wakeup parameter for PCI HCD suspend · 4147200d
      Alan Stern 提交于
      This patch (as1385) adds a "do_wakeup" parameter to the pci_suspend
      method used by PCI-based host controller drivers.  ehci-hcd in
      particular needs to know whether or not to enable wakeup when
      suspending a controller.  Although that information is currently
      available through device_may_wakeup(), when support is added for
      runtime suspend this will no longer be true.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4147200d