kernel/drivers/usb/core/hcd-pci.c, branch linux-4.3.y

USB / PM: Drop CONFIG_PM_RUNTIME from the USB core

2014-12-03T23:51:54Z

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so quite a few depend on CONFIG_PM (or even dropped in some cases). Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code and documentation. Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern Acked-by: Greg Kroah-Hartman

USB: core: hcd-pci: free IRQ before disabling PCI device when shutting down

2014-07-22T23:30:58Z

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] [] dump_stack+0x48/0x60 [ 568.987294] [] warn_slowpath_common+0x7f/0xa0 [ 569.003887] [] warn_slowpath_fmt+0x2e/0x30 [ 569.009092] [] remove_proc_entry+0x165/0x170 [ 569.014476] [] unregister_irq_proc+0xaa/0xc0 [ 569.019858] [] free_desc+0x1f/0x60 [ 569.024346] [] irq_free_descs+0x3a/0x80 [ 569.029283] [] irq_dispose_mapping+0x2d/0x50 [ 569.034666] [] mp_unmap_irq+0x73/0xa0 [ 569.039423] [] acpi_unregister_gsi_ioapic+0x2b/0x40 [ 569.045431] [] acpi_unregister_gsi+0xf/0x20 [ 569.050725] [] acpi_pci_irq_disable+0x4b/0x50 [ 569.056196] [] pcibios_disable_device+0x18/0x20 [ 569.061848] [] do_pci_disable_device+0x4d/0x60 [ 569.067410] [] pci_disable_device+0x47/0xb0 [ 569.077814] [] usb_hcd_pci_shutdown+0x31/0x40 [ 569.083285] [] pci_device_shutdown+0x19/0x50 [ 569.088667] [] device_shutdown+0x14/0x120 [ 569.093777] [] kernel_restart_prepare+0x2d/0x30 [ 569.099429] [] kernel_restart+0xe/0x60 [ 569.109028] [] SYSC_reboot+0x191/0x220 [ 569.159269] [] SyS_reboot+0x1a/0x20 [ 569.163843] [] sysenter_do_call+0x12/0x16 [ 569.168951] ---[ end trace ccc1ec4471c289c9 ]--- Tested-by: Aaron Lu Signed-off-by: Jiang Liu Reviewed-by: Huang Rui Signed-off-by: Greg Kroah-Hartman

usb: remove redundant D0 power state set

2014-05-27T22:18:48Z

Pci_enable_device() will set device power state to D0, so it's no need to do it again after call pci_enable_device(). Signed-off-by: Yijing Wang Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: fix crash during hotplug of PCI USB controller card

2014-04-16T20:59:12Z

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: Alan Stern Reported-by: Stefani Seibold Tested-by: Stefani Seibold CC: Signed-off-by: Greg Kroah-Hartman

usb: hcd: move controller wakeup setting initialization to individual driver

2013-12-09T02:06:46Z

Individual controller driver has different requirement for wakeup setting, so move it from core to itself. In order to align with current etting the default wakeup setting is enabled (except for chipidea host). Pass compile test with below commands: make O=outout/all allmodconfig make -j$CPU_NUM O=outout/all drivers/usb Signed-off-by: Peter Chen Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: core: implement AMD remote wakeup quirk

2013-09-26T00:24:37Z

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: Huang Rui Suggested-by: Alan Stern Acked-by: Alan Stern Acked-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

usb: fix some scripts/kernel-doc warnings

2013-08-03T03:30:14Z

When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi Signed-off-by: Greg Kroah-Hartman

USB: improve port transitions when EHCI starts up

2013-03-28T21:45:57Z

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: Alan Stern Tested-by: Jenya Y Signed-off-by: Greg Kroah-Hartman

USB: xhci: correctly enable interrupts

2013-03-15T19:07:53Z

xhci has its own interrupt enabling routine, which will try to use MSI-X/MSI if present. So the usb core shouldn't try to enable legacy interrupts; on some machines the xhci legacy IRQ setting is invalid. v3: Be careful to not break XHCI_BROKEN_MSI workaround (by trenn) Cc: Bjorn Helgaas Cc: Oliver Neukum Cc: Thomas Renninger Cc: Yinghai Lu Cc: Frederik Himpe Cc: David Haerdeman Cc: Alan Stern Acked-by: Sarah Sharp Reviewed-by: Thomas Renninger Signed-off-by: Hannes Reinecke Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2

2012-06-13T20:11:39Z

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 151b61284776be2d6f02d48c23c3625678960b97 (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: Alan Stern Tested-by: Dâniel Fraga Tested-by: Andrey Rahmatullin Tested-by: Steven Rostedt Cc: stable Reviewed-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman