aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/core/hcd-pci.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2022-09-01USB: hcd-pci: Drop the unused id parameter from usb_hcd_pci_probe()Heikki Krogerus1-6/+1
Since the HC driver is now passed to the function with its own parameter (it used to be picked from id->driver_data), the id parameter serves no purpose. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20220831125052.71584-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23USB: hcd-pci: Fully suspend across freeze/thaw cycleEvan Green1-2/+2
The documentation for the freeze() method says that it "should quiesce the device so that it doesn't generate IRQs or DMA". The unspoken consequence of not doing this is that MSIs aimed at non-boot CPUs may get fully lost if they're sent during the period where the target CPU is offline. The current callbacks for USB HCD do not fully quiesce interrupts, specifically on XHCI. Change to use the full suspend/resume flow for freeze/thaw to ensure interrupts are fully quiesced. This fixes issues where USB devices fail to thaw during hibernation because XHCI misses its interrupt and cannot recover. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20220421103751.v3.2.I8226c7fdae88329ef70957b96a39b346c69a914e@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-21usb: Prepare cleanup of powerpc's asm/prom.hChristophe Leroy1-1/+0
powerpc's asm/prom.h brings some headers that it doesn't need itself. In order to clean it up in a further step, first clean all files that include asm/prom.h Some files don't need asm/prom.h at all. For those ones, just remove inclusion of asm/prom.h Some files don't need any of the items provided by asm/prom.h, but need some of the headers included by asm/prom.h. For those ones, add the needed headers that are brought by asm/prom.h at the moment, then remove asm/prom.h Some files really need asm/prom.h but also need some of the headers included by asm/prom.h. For those one, leave asm/prom.h but also add the needed headers so that they can be removed from asm/prom.h in a later step. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/295e87a3094a92784657f7060fb0927e762a2e3c.1650011506.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-26Merge tag 'usb-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds1-1/+1
Pull USB/Thunderbolt updates from Greg KH: "Here is the big set of USB and Thunderbolt changes for 5.18-rc1. Nothing major in here, just lots of little improvements and cleanups and new device support. Highlights are: - list iterator fixups for when we walk past the end of the list (a common problem that was cut/pasted in almost all USB gadget drivers) - xen USB driver "hardening" for malicious hosts - xhci driver updates and fixes for more hardware types - xhci debug cable fixes to make it actually work again - usb gadget audio driver improvements - usb gadget storage fixes to work with OS-X - lots of other small usb gadget fixes and updates - USB DWC3 driver improvements for more hardware types - Lots of other small USB driver improvements - DTS updates for some USB platforms All of these have been in linux-next for a while with no reported issues" * tag 'usb-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (172 commits) usb: gadget: fsl_qe_udc: Add missing semicolon in qe_ep_dequeue() dt-bindings: usb: mtk-xhci: add compatible for mt8186 usb: dwc3: Issue core soft reset before enabling run/stop usb: gadget: Makefile: remove ccflags-y USB: usb-storage: Fix use of bitfields for hardware data in ene_ub6250.c usb: gadget: eliminate anonymous module_init & module_exit usb: usbip: eliminate anonymous module_init & module_exit xen/usb: harden xen_hcd against malicious backends usb: dwc3: gadget: Wait for ep0 xfers to complete during dequeue usb: dwc3: gadget: move cmd_endtransfer to extra function usb: dwc3: gadget: ep_queue simplify isoc start condition xen/usb: don't use arbitrary_virt_to_machine() usb: isp1760: remove redundant max_packet() macro usb: oxu210hp-hcd: remove redundant call to max_packet() macro usb: common: usb-conn-gpio: Make VBUS supply completely optional USB: storage: ums-realtek: fix error code in rts51x_read_mem() usb: early: xhci-dbc: Fix xdbc number parsing usb: early: xhci-dbc: Remove duplicate keep parsing x86/tsc: Be consistent about use_tsc_delay() usb: gadget: udc: s3c2410: remove usage of list iterator past the loop body ...
2022-03-08PM: sleep: Add device name to suspend_report_result()Youngjin Jang1-2/+2
Currently, suspend_report_result() prints only function information. If any driver uses a common PM function, nobody knows who exactly called the failing function. A device pinter is needed to recognize the failing device. For example: PM: dpm_run_callback(): pnp_bus_suspend+0x0/0x10 returns 0 PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns 0 become after the change: serial 00:05: PM: dpm_run_callback(): pnp_bus_suspend+0x0/0x10 returns 0 pci 0000:00:01.3: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns 0 Signed-off-by: Youngjin Jang <yj84.jang@samsung.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-01-26USB: hcd-pci: Use PCI_STD_NUM_BARS when checking standard BARsBjorn Helgaas1-1/+1
usb_hcd_pci_probe() searches for an I/O BAR using a combination of PCI_STD_NUM_BARS (to control loop iteration) and PCI_ROM_RESOURCE (to check whether the loop exits without finding anything). Use PCI_STD_NUM_BARS consistently. No functional change since PCI_STD_NUM_BARS == PCI_ROM_RESOURCE, but this removes a dependency on that relationship and makes the code read better. Fixes: c9c13ba428ef ("PCI: Add PCI_STD_NUM_BARS for the number of standard BARs") Cc: Denis Efremov <efremov@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20220121183330.1141702-1-helgaas@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-28usb: core: Replace in_interrupt() in commentsAhmed S. Darwish1-2/+4
The usage of in_interrupt() in drivers is phased out for various reasons. Various comments use !in_interrupt() to describe calling context for functions which might sleep. That's wrong because the calling context has to be preemptible task context, which is not what !in_interrupt() describes. Replace !in_interrupt() with more accurate plain text descriptions. The comment for usb_hcd_poll_rh_status() is misleading as this function is called from all kinds of contexts including preemptible task context. Remove it as there is obviously no restriction. Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: linux-usb@vger.kernel.org Link: https://lore.kernel.org/r/20201019101110.851821025@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18usb: hcd: Fix use after free in usb_hcd_pci_remove()Andy Shevchenko1-1/+4
On the removal stage we put a reference to the controller structure and if it's not used anymore it gets freed, but later we try to dereference a pointer to a member of that structure. Copy necessary field to a temporary variable to avoid use after free. Fixes: 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI devices") Reported-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/linux-usb/30a8c4ca-64c2-863b-cfcd-0970599c0ba3@huawei.com/ Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200814182218.71957-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21usb: hcd: Try MSI interrupts on PCI devicesAndy Shevchenko1-4/+10
It appears that some platforms share same IRQ line between several devices, some of which are EHCI and OHCI controllers. This is neither practical nor performance-wise, especially in the case when they are supporting MSI. In order to improve the situation try to allocate MSI and fallback to legacy IRQ if no MSI available. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200702143045.23429-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-15usb: hci: add hc_driver as argument for usb_hcd_pci_probeVinod Koul1-3/+4
usb_hcd_pci_probe expects users to call this with driver_data set as hc_driver, that limits the possibility of using the driver_data for driver data. Add hc_driver as argument to usb_hcd_pci_probe and modify the callers ehci/ohci/xhci/uhci to pass hc_driver as argument and freeup the driver_data used Tested xhci driver on Dragon-board RB3, compile tested ehci, ohci and uhci. [For all but the xHCI parts] [For the xhci part] Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200514122039.300417-2-vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-06remove ioremap_nocache and devm_ioremap_nocacheChristoph Hellwig1-1/+1
ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Arnd Bergmann <arnd@arndb.de>
2019-10-14PCI: Add PCI_STD_NUM_BARS for the number of standard BARsDenis Efremov1-1/+1
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RESOURCE_END" rather than something the typical "i < PCI_STD_NUM_BARS". Add a definition for PCI_STD_NUM_BARS and change loops to use the more idiomatic C style to help avoid fencepost errors. Link: https://lore.kernel.org/r/20190927234026.23342-1-efremov@linux.com Link: https://lore.kernel.org/r/20190927234308.23935-1-efremov@linux.com Link: https://lore.kernel.org/r/20190916204158.6889-3-efremov@linux.com Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Sebastian Ott <sebott@linux.ibm.com> # arch/s390/ Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> # video/fbdev/ Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> # pci/controller/dwc/ Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> # scsi/pm8001/ Acked-by: Martin K. Petersen <martin.petersen@oracle.com> # scsi/pm8001/ Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # memstick/
2019-09-02Merge 5.3-rc7 into usb-nextGreg Kroah-Hartman1-22/+8
We need the usb fixes in here for testing Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-28usb: hcd: use managed device resourcesSchmid, Carsten1-22/+8
Using managed device resources in usb_hcd_pci_probe() allows devm usage for resource subranges, such as the mmio resource for the platform device created to control host/device mode mux, which is a xhci extended capability, and sits inside the xhci mmio region. If managed device resources are not used then "parent" resource is released before subrange at driver removal as .remove callback is called before the devres list of resources for this device is walked and released. This has been observed with the xhci extended capability driver causing a use-after-free which is now fixed. An additional nice benefit is that error handling on driver initialisation is simplified much. Signed-off-by: Carsten Schmid <carsten_schmid@mentor.com> Tested-by: Carsten Schmid <carsten_schmid@mentor.com> Reviewed-by: Mathias Nyman <mathias.nyman@linux.intel.com> Fixes: fa31b3cb2ae1 ("xhci: Add Intel extended cap / otg phy mux handling") Cc: <stable@vger.kernel.org> # v4.19+ Link: https://lore.kernel.org/r/1566569488679.31808@mentor.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-25USB: core: hcd-pci: Use dev_get_drvdata where possibleChuhong Yuan1-2/+1
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Link: https://lore.kernel.org/r/20190724131838.1931-1-hslester96@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-05usb: Don't die twice if PCI xhci host is not responding in resumeMathias Nyman1-2/+0
usb_hc_died() should only be called once, and with the primary HCD as parameter. It will mark both primary and secondary hcd's dead. Remove the extra call to usb_cd_died with the shared hcd as parameter. Fixes: ff9d78b36f76 ("USB: Set usb_hcd->state and flags for shared roothubs") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-04USB: core: Remove redundant license textGreg Kroah-Hartman1-14/+0
Now that the SPDX tag is in all USB files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-04USB: add SPDX identifiers to all remaining files in drivers/usb/Greg Kroah-Hartman1-0/+1
It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the drivers/usb/ and include/linux/usb* files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-15USB / PCI / PM: Allow the PCI core to do the resume cleanupRafael J. Wysocki1-6/+1
hcd_pci_resume_noirq() used as a universal _resume_noirq handler for PCI USB controllers calls pci_back_from_sleep() which is unnecessary and may become problematic. It is unnecessary, because the PCI bus type carries out post-suspend cleanup of all PCI devices during resume and that covers all things done by the pci_back_from_sleep(). There is no reason why USB cannot follow all of the other PCI devices in that respect. It will become problematic after subsequent changes that make it possible to go back to sleep again after executing dpm_resume_noirq() if no valid system wakeup events have been detected at that point. Namely, calling pci_back_from_sleep() at the _resume_noirq stage will cause the wakeup status of the devices in question to be cleared and if any of them has triggered system wakeup, that event may be missed then. For the above reasons, drop the pci_back_from_sleep() invocation from hcd_pci_resume_noirq(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-13usb: hcd: out of bounds access in for_each_companionRobert Dobrowolski1-0/+9
On BXT platform Host Controller and Device Controller figure as same PCI device but with different device function. HCD should not pass data to Device Controller but only to Host Controllers. Checking if companion device is Host Controller, otherwise skip. Cc: <stable@vger.kernel.org> Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-17Merge tag 'usb-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds1-1/+1
Pull USB updates from Greg KH: "Here is the big USB patchset for 4.6-rc1. The normal mess is here, gadget and xhci fixes and updates, and lots of other driver updates and cleanups as well. Full details are in the shortlog. All have been in linux-next for a while with no reported issues" * tag 'usb-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (266 commits) USB: core: let USB device know device node usb: devio: Add ioctl to disallow detaching kernel USB drivers. usb: gadget: f_acm: Fix configfs attr name usb: udc: lpc32xx: remove USB PLL and USB OTG clock management usb: udc: lpc32xx: remove direct access to clock controller registers usb: udc: lpc32xx: switch to clock prepare/unprepare model usb: renesas_usbhs: gadget: fix giveback status code in usbhsg_pipe_disable() usb: gadget: renesas_usb3: Use ARCH_RENESAS usb: dwc2: Fix issues in dwc2_complete_non_isoc_xfer_ddma() usb: dwc2: Add support for Lantiq ARX and XRX SoCs usb: phy: generic: Handle late registration of gadget usb: gadget: bdc_udc: fix race condition in bdc_udc_exit() usb: musb: core: added missing const qualifier to musb_hdrc_platform_data::config usb: dwc2: Move host-specific core functions into hcd.c usb: dwc2: Move register save and restore functions usb: dwc2: Use kmem_cache_free() usb: dwc2: host: If using uframe scheduler, end splits better usb: dwc2: host: Totally redo the microframe scheduler usb: dwc2: host: Properly set even/odd frame usb: dwc2: host: Add dwc2_hcd_get_future_frame_number() call ...
2016-02-05PCI: Remove includes of asm/pci-bridge.hBjorn Helgaas1-1/+0
Drivers should include asm/pci-bridge.h only when they need the arch- specific things provided there. Outside of the arch/ directories, the only drivers that actually need things provided by asm/pci-bridge.h are the powerpc RPA hotplug drivers in drivers/pci/hotplug/rpa*. Remove the includes of asm/pci-bridge.h from the other drivers, adding an include of linux/pci.h if necessary. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-01-24usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus USB3.1 devicesMathias Nyman1-1/+1
Add a new USB_SPEED_SUPER_PLUS device speed, and make sure usb core can handle the new speed. In most cases the behaviour is the same as with USB_SPEED_SUPER SuperSpeed devices. In a few places we add a "Plus" string to inform the user of the new speed. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-12-04USB / PM: Drop CONFIG_PM_RUNTIME from the USB coreRafael J. Wysocki1-11/+0
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 <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-22USB: core: hcd-pci: free IRQ before disabling PCI device when shutting downJiang Liu1-0/+2
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: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-27usb: remove redundant D0 power state setYijing Wang1-1/+0
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 <wangyijing@huawei.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-04-16USB: fix crash during hotplug of PCI USB controller cardAlan Stern1-1/+1
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 <stern@rowland.harvard.edu> Reported-by: Stefani Seibold <stefani@seibold.net> Tested-by: Stefani Seibold <stefani@seibold.net> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-08usb: hcd: move controller wakeup setting initialization to individual driverPeter Chen1-0/+1
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 <peter.chen@freescale.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-25usb: core: implement AMD remote wakeup quirkHuang Rui1-0/+3
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 <ray.huang@amd.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-03usb: fix some scripts/kernel-doc warningsYacine Belkadi1-0/+2
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 <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-28USB: improve port transitions when EHCI starts upAlan Stern1-85/+129
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 <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-15USB: xhci: correctly enable interruptsHannes Reinecke1-9/+14
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 <bhelgaas@google.com> Cc: Oliver Neukum <oneukum@suse.de> Cc: Thomas Renninger <trenn@suse.de> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Frederik Himpe <fhimpe@vub.ac.be> Cc: David Haerdeman <david@hardeman.nu> Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reviewed-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Hannes Reinecke <hare@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-13USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2Alan Stern1-9/+0
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 <stern@rowland.harvard.edu> Tested-by: Dâniel Fraga <fragabr@gmail.com> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Steven Rostedt <rostedt@goodmis.org> Cc: stable <stable@vger.kernel.org> Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-24USB: EHCI: fix crash during suspend on ASUS computersAlan Stern1-0/+9
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: Alan Stern <stern@rowland.harvard.edu> Tested-by: Steven Rostedt <rostedt@goodmis.org> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Oleksij Rempel (fishor) <bug-track@fisher-privat.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-28usb: fix defined but not used warnings in hcd-pci.cPaul Gortmaker1-0/+2
Shows up on ia64 builds (and possibly elsewhere) for configs that don't set PM_RUNTIME or PM_SLEEP as follows: drivers/usb/core/hcd-pci.c:383:12: warning: 'suspend_common' defined but not used drivers/usb/core/hcd-pci.c:438:12: warning: 'resume_common' defined but not used As per above, the functions are only used if RUNTIME/SLEEP are set, so make the two functions conditional on these Kconfig values. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-14USB: Don't fail USB3 probe on missing legacy PCI IRQ.Sarah Sharp1-1/+4
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: Alex Shi <alex.shi@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2011-11-14USB: Remove the SAW_IRQ hcd flagAlan Stern1-4/+0
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: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-18USB: irq: Remove IRQF_DISABLEDYong Zhang1-1/+1
This flag is a NOOP and can be removed now. Signed-off-by: Yong Zhang <yong.zhang0@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-16Merge branch 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6Linus Torvalds1-19/+37
* 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (172 commits) USB: Add support for SuperSpeed isoc endpoints xhci: Clean up cycle bit math used during stalls. xhci: Fix cycle bit calculation during stall handling. xhci: Update internal dequeue pointers after stalls. USB: Disable auto-suspend for USB 3.0 hubs. USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol. xhci: Return canceled URBs immediately when host is halted. xhci: Fixes for suspend/resume of shared HCDs. xhci: Fix re-init on power loss after resume. xhci: Make roothub functions deal with device removal. xhci: Limit roothub ports to 15 USB3 & 31 USB2 ports. xhci: Return a USB 3.0 hub descriptor for USB3 roothub. xhci: Register second xHCI roothub. xhci: Change xhci_find_slot_id_by_port() API. xhci: Refactor bus suspend state into a struct. xhci: Index with a port array instead of PORTSC addresses. USB: Set usb_hcd->state and flags for shared roothubs. usb: Make core allocate resources per PCI-device. usb: Store bus type in usb_hcd, not in driver flags. usb: Change usb_hcd->bandwidth_mutex to a pointer. ...
2011-03-15PM: Remove CONFIG_PM_OPSRafael J. Wysocki1-2/+2
After redefining CONFIG_PM to depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME) the CONFIG_PM_OPS option is redundant and can be replaced with CONFIG_PM. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-03-13USB: Set usb_hcd->state and flags for shared roothubs.Sarah Sharp1-4/+23
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-13usb: Make usb_hcd_pci_probe labels more descriptive.Sarah Sharp1-10/+10
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-07USB: move usbcore away from hcd->stateAlan Stern1-7/+6
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: Alan Stern <stern@rowland.harvard.edu> Tested-by: Alex Terekhov <a.terekhov@gmail.com> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-01-14xHCI: synchronize irq in xhci_suspend()Andiry Xu1-1/+6
Synchronize the interrupts instead of free them in xhci_suspend(). This will prevent a double free when the host is suspended and then the card removed. Set the flag hcd->msix_enabled when using MSI-X, and check the flag in suspend_common(). MSI-X synchronization will be handled by xhci_suspend(), and MSI/INTx will be synchronized in suspend_common(). This patch should be queued for the 2.6.37 stable tree. Reported-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2010-11-16USB: make usb_mark_last_busy use pm_runtime_mark_last_busyMing Lei1-1/+0
Since the runtime-PM core already defines a .last_busy field in device.power, this patch uses it to replace the .last_busy field defined in usb_device and uses pm_runtime_mark_last_busy to implement usb_mark_last_busy. Signed-off-by: Ming Lei <tom.leiming@gmail.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-10-22OHCI: work around for nVidia shutdown problemAlan Stern1-1/+3
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: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: David Brownell <david-b@pacbell.net> Tested-by: Pali Rohár <pali.rohar@gmail.com> CC: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-10USB: core: hcd-pci: use for_each_pci_dev()Kulikov Vasiliy1-4/+1
Use for_each_pci_dev() to simplify the code. Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-10USB: add runtime PM for PCI-based host controllersAlan Stern1-14/+62
This patch (as1386) adds runtime-PM support for PCI-based USB host controllers. By default autosuspend is disallowed; the user must enable it by writing "auto" to the controller's power/control sysfs attribute. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-10USB: fix race between root-hub wakeup & controller suspendAlan Stern1-0/+12
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: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-10USB: add do_wakeup parameter for PCI HCD suspendAlan Stern1-1/+3
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: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>