1. 25 1月, 2016 1 次提交
  2. 04 12月, 2014 1 次提交
  3. 23 7月, 2014 1 次提交
    • J
      USB: core: hcd-pci: free IRQ before disabling PCI device when shutting down · c5946f9d
      Jiang Liu 提交于
      The assigned IRQ should be freed before calling pci_disable_device()
      when shutting down system, otherwise it will cause following warning.
      [  568.879482] ------------[ cut here ]------------
      [  568.884236] WARNING: CPU: 1 PID: 3300 at /home/konrad/ssd/konrad/xtt-i386/bootstrap/linux-usb/fs/proc/generic.c:521 remove_proc_entry+0x165/0x170()
      [  568.897846] remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'ohci_hcd:usb4'
      [  568.907430] Modules linked in: dm_multipath dm_mod iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c_generic sg sd_mod crct10dif_generic crc_t10dif crct10dif_common radeon fbcon tileblit ttm font bitblit softcursor ata_generic ahci libahci drm_kms_helper skge r8169 libata mii scsi_mod wmi acpi_cpufreq
      [  568.938539] CPU: 1 PID: 3300 Comm: init Tainted: G        W     3.16.0-rc5upstream-01651-g03b9189 #1
      [  568.947946] Hardware name: ECS A780GM-A Ultra/A780GM-A Ultra, BIOS 080015  04/01/2010
      [  568.956008]  00000209 ed0f1cd0 c1617946 c175403c ed0f1d00 c1090c3f c1754084 ed0f1d2c
      [  568.964068]  00000ce4 c175403c 00000209 c11f22a5 c11f22a5 f755e8c0 ed0f1d78 f755e90d
      [  568.972128]  ed0f1d18 c1090cde 00000009 ed0f1d10 c1754084 ed0f1d2c ed0f1d60 c11f22a5
      [  568.980194] Call Trace:
      [  568.982715]  [<c1617946>] dump_stack+0x48/0x60
      [  568.987294]  [<c1090c3f>] warn_slowpath_common+0x7f/0xa0
      [  569.003887]  [<c1090cde>] warn_slowpath_fmt+0x2e/0x30
      [  569.009092]  [<c11f22a5>] remove_proc_entry+0x165/0x170
      [  569.014476]  [<c10da6ca>] unregister_irq_proc+0xaa/0xc0
      [  569.019858]  [<c10d582f>] free_desc+0x1f/0x60
      [  569.024346]  [<c10d58aa>] irq_free_descs+0x3a/0x80
      [  569.029283]  [<c10d9e9d>] irq_dispose_mapping+0x2d/0x50
      [  569.034666]  [<c1078fd3>] mp_unmap_irq+0x73/0xa0
      [  569.039423]  [<c107196b>] acpi_unregister_gsi_ioapic+0x2b/0x40
      [  569.045431]  [<c107180f>] acpi_unregister_gsi+0xf/0x20
      [  569.050725]  [<c1339cad>] acpi_pci_irq_disable+0x4b/0x50
      [  569.056196]  [<c14daa38>] pcibios_disable_device+0x18/0x20
      [  569.061848]  [<c130123d>] do_pci_disable_device+0x4d/0x60
      [  569.067410]  [<c13012b7>] pci_disable_device+0x47/0xb0
      [  569.077814]  [<c14800b1>] usb_hcd_pci_shutdown+0x31/0x40
      [  569.083285]  [<c1304b19>] pci_device_shutdown+0x19/0x50
      [  569.088667]  [<c13fda64>] device_shutdown+0x14/0x120
      [  569.093777]  [<c10ac29d>] kernel_restart_prepare+0x2d/0x30
      [  569.099429]  [<c10ac41e>] kernel_restart+0xe/0x60
      [  569.109028]  [<c10ac611>] SYSC_reboot+0x191/0x220
      [  569.159269]  [<c10ac6ba>] SyS_reboot+0x1a/0x20
      [  569.163843]  [<c161c718>] sysenter_do_call+0x12/0x16
      [  569.168951] ---[ end trace ccc1ec4471c289c9 ]---
      Tested-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Reviewed-by: NHuang Rui <ray.huang@amd.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5946f9d
  4. 28 5月, 2014 1 次提交
  5. 17 4月, 2014 1 次提交
    • A
      USB: fix crash during hotplug of PCI USB controller card · a2ff864b
      Alan Stern 提交于
      The code in hcd-pci.c that matches up EHCI controllers with their
      companion UHCI or OHCI controllers assumes that the private drvdata
      fields don't get set too early.  However, it turns out that this field
      gets set by usb_create_hcd(), before hcd-pci expects it, and this can
      result in a crash when two controllers are probed in parallel (as can
      happen when a new controller card is hotplugged).
      
      The companions_rwsem lock was supposed to prevent this sort of thing,
      but usb_create_hcd() is called outside the scope of the rwsem.
      
      A simple solution is to check that the root-hub pointer has been
      initialized as well as the drvdata field.  This doesn't happen until
      usb_add_hcd() is called; that call and the check are both protected by
      the rwsem.
      
      This patch should be applied to stable kernels from 3.10 onward.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NStefani Seibold <stefani@seibold.net>
      Tested-by: NStefani Seibold <stefani@seibold.net>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2ff864b
  6. 09 12月, 2013 1 次提交
  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. 03 8月, 2013 1 次提交
  9. 29 3月, 2013 1 次提交
    • A
      USB: improve port transitions when EHCI starts up · 05768918
      Alan Stern 提交于
      It seems to be getting more common recently for EHCI host controllers
      to be probed after their companion UHCI or OHCI controllers.  This may
      be caused partly by splitting the ehci-pci driver out from ehci-hcd,
      or it may be caused by changes in the way the kernel does driver
      probing.
      
      Regardless, it has a tendency to cause problems.  When an EHCI
      controller is initialized, it takes ownership of all the ports away
      from the companions.  In effect, it forcefully disconnects all the USB
      devices that may already be using a companion controller.
      
      This patch (as1672b) tries to make the transition more orderly by
      deconfiguring the root hubs for all the companion controllers before
      initializing the EHCI controller, and reconfiguring them afterward.
      The result is a soft disconnect rather than a hard one.
      
      Internally, the patch refactors the code involved in associating EHCI
      controllers with their companions.  The old approach, in which a
      single function is called with an argument telling it what to do (the
      companion_action enum), has been replaced with a scheme using multiple
      callback functions, each performing a single task.
      
      This patch won't solve all the problems people encounter when their
      EHCI controllers start up, but it will at least reduce the number of
      error messages generated by the unexpected disconnections.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NJenya Y <jy.gerstmaier@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      05768918
  10. 16 3月, 2013 1 次提交
  11. 14 6月, 2012 1 次提交
    • A
      USB: add NO_D3_DURING_SLEEP flag and revert 151b6128 · c2fb8a3f
      Alan Stern 提交于
      This patch (as1558) 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.
      
      A similar patch has already been applied as commit
      151b6128 (USB: EHCI: fix crash during
      suspend on ASUS computers).  The patch supersedes that one and reverts
      it.  There are two differences:
      
      	The old patch added the flag at the USB level; this patch
      	adds it at the PCI level.
      
      	The old patch applied to all chipsets with the same vendor,
      	subsystem vendor, and product IDs; this patch makes an
      	exception for a known-good system (based on DMI information).
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NDâniel Fraga <fragabr@gmail.com>
      Tested-by: NAndrey Rahmatullin <wrar@wrar.name>
      Tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2fb8a3f
  12. 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
  13. 29 2月, 2012 1 次提交
  14. 15 2月, 2012 1 次提交
    • S
      USB: Don't fail USB3 probe on missing legacy PCI IRQ. · 68d07f64
      Sarah Sharp 提交于
      Intel has a PCI USB xhci host controller on a new platform. It doesn't
      have a line IRQ definition in BIOS.  The Linux driver refuses to
      initialize this controller, but Windows works well because it only depends
      on MSI.
      
      Actually, Linux also can work for MSI.  This patch avoids the line IRQ
      checking for USB3 HCDs in usb core PCI probe.  It allows the xHCI driver
      to try to enable MSI or MSI-X first.  It will fail the probe if MSI
      enabling failed and there's no legacy PCI IRQ.
      
      This patch should be backported to kernels as old as 2.6.32.
      Signed-off-by: NAlex Shi <alex.shi@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      68d07f64
  15. 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
  16. 18 9月, 2011 1 次提交
  17. 15 3月, 2011 1 次提交
  18. 14 3月, 2011 2 次提交
    • 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 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
  19. 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
  20. 15 1月, 2011 1 次提交
  21. 17 11月, 2010 1 次提交
  22. 23 10月, 2010 1 次提交
    • A
      OHCI: work around for nVidia shutdown problem · 3df7169e
      Alan Stern 提交于
      This patch (as1417) fixes a problem affecting some (or all) nVidia
      chipsets.  When the computer is shut down, the OHCI controllers
      continue to power the USB buses and evidently they drive a Reset
      signal out all their ports.  This prevents attached devices from going
      to low power.  Mouse LEDs stay on, for example, which is disconcerting
      for users and a drain on laptop batteries.
      
      The fix involves leaving each OHCI controller in the OPERATIONAL state
      during system shutdown rather than putting it in the RESET state.
      Although this nominally means the controller is running, in fact it's
      not doing very much since all the schedules are all disabled.  However
      there is ongoing DMA to the Host Controller Communications Area, so
      the patch also disables the bus-master capability of all PCI USB
      controllers after the shutdown routine runs.
      
      The fix is applied only to nVidia-based PCI OHCI controllers, so it
      shouldn't cause problems on systems using other hardware.  As an added
      safety measure, in case the kernel encounters one of these running
      controllers during boot, the patch changes quirk_usb_handoff_ohci()
      (which runs early on during PCI discovery) to reset the controller
      before anything bad can happen.
      Reported-by: NPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: David Brownell <david-b@pacbell.net>
      Tested-by: NPali Rohár <pali.rohar@gmail.com>
      CC: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3df7169e
  23. 11 8月, 2010 7 次提交
  24. 21 5月, 2010 1 次提交
  25. 27 2月, 2010 1 次提交
    • A
      USB: implement non-tree resume ordering constraints for PCI host controllers · 6d19c009
      Alan Stern 提交于
      This patch (as1331) adds non-tree ordering constraints needed for
      proper resume of PCI USB host controllers from hibernation.  The main
      issue is that non-high-speed devices must not be resumed before the
      high-speed root hub, because it is the ehci_bus_resume() routine which
      takes care of handing the device connection over to the companion
      controller.  If the device resume is attempted before the handover
      then the device won't be found and it will be treated as though it had
      disconnected.
      
      The patch adds a new field to the usb_bus structure; for each
      full/low-speed bus this field will contain a pointer to the companion
      high-speed bus (if one exists).  It is used during normal device
      resume; if the hs_companion pointer isn't NULL then we wait for the
      root-hub device on the hs_companion bus.
      
      A secondary issue is that an EHCI controlller shouldn't be resumed
      before any of its companions.  On some machines I have observed
      handovers failing if the companion controller is reinitialized after
      the handover.  Thus, the EHCI resume routine must wait for the
      companion controllers to be resumed.
      
      The patch also fixes a small bug in usb_hcd_pci_probe(); an error path
      jumps to the wrong label, causing a memory leak.
      
      [rjw: Fixed compilation for CONFIG_PM_SLEEP unset.]
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      6d19c009
  26. 16 12月, 2009 1 次提交
  27. 16 6月, 2009 2 次提交
  28. 18 2月, 2009 1 次提交
  29. 28 1月, 2009 2 次提交
    • R
      USB: Fix suspend-resume of PCI USB controllers · a15d95a0
      Rafael J. Wysocki 提交于
      Commit a0d4922d
      (USB: fix up suspend and resume for PCI host controllers) attempted
      to fix the suspend-resume of PCI USB controllers, but unfortunately
      it did that incorrectly and interrupts are left enabled by the USB
      controllers' ->suspend_late() callback as a result.  This leads to
      serious problems during suspend which are very difficult to debug.
      
      Fix the issue by removing the ->suspend_late() callback of PCI
      USB controllers and moving the code from there to the ->suspend()
      callback executed with interrupts enabled.  Additionally, make
      the ->resume() callback of PCI USB controllers execute
      pci_enable_wake(dev, PCI_D0, false) to disable wake-up from the
      full power state (PCI_D0).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Tested-by: NAndrey Borzenkov <arvidjaar@mail.ru>
      Tested-by: N"Jeff Chua" <jeff.chua.linux@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: "Zdenek Kabelac" <zdenek.kabelac@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a15d95a0
    • A
      USB: don't enable wakeup by default for PCI host controllers · bcca06ef
      Alan Stern 提交于
      This patch (as1199) changes the initial wakeup settings for PCI USB
      host controllers.  The controllers are marked as capable of waking the
      system, but wakeup is not enabled by default.
      
      It turns out that enabling wakeup for USB host controllers has a lot
      of bad consequences.  As the simplest example, if a USB mouse or
      keyboard is unplugged immediately after the computer is put to sleep,
      the unplug will cause the system to wake back up again!  We are better
      off marking them as wakeup-capable and leaving wakeup disabled.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NRafael J. Wysocki <rjw@sisk.pl>
      CC: David Brownell <david-b@pacbell.net>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bcca06ef
  30. 08 1月, 2009 2 次提交
    • A
      USB: automatically enable wakeup for PCI host controllers · 6fd9086a
      Alan Stern 提交于
      This patch (as1193b) enables wakeup during initialization for all PCI
      host controllers, and it removes some code (and comments!) that are no
      longer needed now that the PCI core automatically initializes wakeup
      settings for all new devices.
      
      The idea is that the bus should initialize wakeup, and the bus glue
      or controller driver should enable it.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6fd9086a
    • A
      USB: fix up suspend and resume for PCI host controllers · a0d4922d
      Alan Stern 提交于
      This patch (as1192) rearranges the USB PCI host controller suspend and
      resume and resume routines:
      
      	Use pci_wake_from_d3() for enabling and disabling wakeup,
      	instead of pci_enable_wake().
      
      	Carry out the actual state change while interrupts are
      	disabled.
      
      	Change the order of the preparations to agree with the
      	general recommendation for PCI devices, instead of
      	messing around with the wakeup settings while the device
      	is in D3.
      
      		In .suspend:
      			Call the underlying driver to disable IRQ
      				generation;
      			pci_wake_from_d3(device_may_wakeup());
      			pci_disable_device();
      
      		In .suspend_late:
      			pci_save_state();
      			pci_set_power_state(D3hot);
      			(for PPC_PMAC) Disable ASIC clocks
      
      		In .resume_early:
      			(for PPC_PMAC) Enable ASIC clocks
      			pci_set_power_state(D0);
      			pci_restore_state();
      
      		In .resume:
      			pci_enable_device();
      			pci_set_master();
      			pci_wake_from_d3(0);
      			Call the underlying driver to reenable IRQ
      				generation
      
      	Add the necessary .suspend_late and .resume_early method
      	pointers to the PCI host controller drivers.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a0d4922d