aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb/host
AgeCommit message (Collapse)AuthorFilesLines
2019-11-04Merge 5.4-rc6 into usb-nextGreg Kroah-Hartman3-21/+59
We need the USB fixes in here to build on top of. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-28usb: xhci: fix __le32/__le64 accessors in debugfs codeBen Dooks (Codethink)1-12/+12
It looks like some of the xhci debug code is passing u32 to functions directly from __le32/__le64 fields. Fix this by using le{32,64}_to_cpu() on these to fix the following sparse warnings; xhci-debugfs.c:205:62: warning: incorrect type in argument 1 (different base types) xhci-debugfs.c:205:62: expected unsigned int [usertype] field0 xhci-debugfs.c:205:62: got restricted __le32 xhci-debugfs.c:206:62: warning: incorrect type in argument 2 (different base types) xhci-debugfs.c:206:62: expected unsigned int [usertype] field1 xhci-debugfs.c:206:62: got restricted __le32 ... [Trim down commit message, sparse warnings were similar -Mathias] Cc: <[email protected]> # 4.15+ Signed-off-by: Ben Dooks <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-28usb: xhci: fix Immediate Data Transfer endiannessSamuel Holland1-0/+2
The arguments to queue_trb are always byteswapped to LE for placement in the ring, but this should not happen in the case of immediate data; the bytes copied out of transfer_buffer are already in the correct order. Add a complementary byteswap so the bytes end up in the ring correctly. This was observed on BE ppc64 with a "Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller [104c:8241]" as a ch341 usb-serial adapter ("1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter") always transmitting the same character (generally NUL) over the serial link regardless of the key pressed. Cc: <[email protected]> # 5.2+ Fixes: 33e39350ebd2 ("usb: xhci: add Immediate Data Transfer support") Signed-off-by: Samuel Holland <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-28xhci: Fix use-after-free regression in xhci clear hub TT implementationMathias Nyman1-9/+45
commit ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") schedules work to clear TT buffer, but causes a use-after-free regression at the same time Make sure hub_tt_work finishes before endpoint is disabled, otherwise the work will dereference already freed endpoint and device related pointers. This was triggered when usb core failed to read the configuration descriptor of a FS/LS device during enumeration. xhci driver queued clear_tt_work while usb core freed and reallocated a new device for the next enumeration attempt. EHCI driver implents ehci_endpoint_disable() that makes sure clear_tt_work has finished before it returns, but xhci lacks this support. usb core will call hcd->driver->endpoint_disable() callback before disabling endpoints, so we want this in xhci as well. The added xhci_endpoint_disable() is based on ehci_endpoint_disable() Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") Cc: <[email protected]> # v5.3 Reported-by: Johan Hovold <[email protected]> Suggested-by: Johan Hovold <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Tested-by: Johan Hovold <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-15USB: host: ohci-at91: Remove unused variable regs in at91_stop_hcNathan Chancellor1-1/+0
drivers/usb/host/ohci-at91.c:118:28: warning: unused variable 'regs' [-Wunused-variable] struct ohci_regs __iomem *regs = hcd->regs; ^ 1 warning generated. Fixes: 9c4567fa0a44 ("USB: host: ohci-at91: completely shutdown the controller in at91_stop_hc()") Signed-off-by: Nathan Chancellor <[email protected]> Acked-by: Nicolas Ferre <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
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/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Sebastian Ott <[email protected]> # arch/s390/ Acked-by: Bartlomiej Zolnierkiewicz <[email protected]> # video/fbdev/ Acked-by: Gustavo Pimentel <[email protected]> # pci/controller/dwc/ Acked-by: Jack Wang <[email protected]> # scsi/pm8001/ Acked-by: Martin K. Petersen <[email protected]> # scsi/pm8001/ Acked-by: Ulf Hansson <[email protected]> # memstick/
2019-10-14Merge 5.4-rc3 into usb-nextGreg Kroah-Hartman3-17/+66
we want the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-07usb: host: xhci-tegra: Add Tegra194 XHCI supportJC Kuo1-0/+30
This commit adds Tegra194 XUSB host mode controller support. This is very similar to the existing Tegra124/Tegra210/Tegra186 XHCI, except 1. the number of ports and PHYs differs 2. the IPFS wrapper being removed 3. mailbox registers address changes Signed-off-by: JC Kuo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-07xhci: tegra: Parameterize mailbox register addressesJC Kuo1-16/+42
Tegra194 XUSB host controller has rearranged mailbox registers. This commit makes mailbox registers address a part of "soc" data so that xhci-tegra driver can be used for Tegra194. Signed-off-by: JC Kuo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04xhci-ext-caps.c: Add missing platform_device_put() on error in ↵Wei Yongjun1-0/+1
xhci_create_intel_xhci_sw_pdev() Add the missing platform_device_put() before return from xhci_create_intel_xhci_sw_pdev() in the error handling case. Fixes: 6ed151f26484 ("xhci-ext-caps.c: Add property to disable Intel SW switch") Signed-off-by: Wei Yongjun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04xhci: Fix NULL pointer dereference in xhci_clear_tt_buffer_complete()Mathias Nyman1-0/+8
udev stored in ep->hcpriv might be NULL if tt buffer is cleared due to a halted control endpoint during device enumeration xhci_clear_tt_buffer_complete is called by hub_tt_work() once it's scheduled, and by then usb core might have freed and allocated a new udev for the next enumeration attempt. Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") Cc: <[email protected]> # v5.3 Reported-by: Johan Hovold <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04xhci: Increase STS_SAVE timeout in xhci_suspend()Kai-Heng Feng1-1/+1
After commit f7fac17ca925 ("xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()"), ASMedia xHCI may fail to suspend. Although the algorithms are essentially the same, the old max timeout is (usec + usec * time of doing readl()), and the new max timeout is just usec, which is much less than the old one. Increase the timeout to make ASMedia xHCI able to suspend again. BugLink: https://bugs.launchpad.net/bugs/1844021 Fixes: f7fac17ca925 ("xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()") Cc: <[email protected]> # v5.2+ Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04xhci: Prevent deadlock when xhci adapter breaks during initBill Kuzeja1-2/+21
The system can hit a deadlock if an xhci adapter breaks while initializing. The deadlock is between two threads: thread 1 is tearing down the adapter and is stuck in usb_unlocked_disable_lpm waiting to lock the hcd->handwidth_mutex. Thread 2 is holding this mutex (while still trying to add a usb device), but is stuck in xhci_endpoint_reset waiting for a stop or config command to complete. A reboot is required to resolve. It turns out when calling xhci_queue_stop_endpoint and xhci_queue_configure_endpoint in xhci_endpoint_reset, the return code is not checked for errors. If the timing is right and the adapter dies just before either of these commands get issued, we hang indefinitely waiting for a completion on a command that didn't get issued. This wasn't a problem before the following fix because we didn't send commands in xhci_endpoint_reset: commit f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset") With the patch I am submitting, a duration test which breaks adapters during initialization (and which deadlocks with the standard kernel) runs without issue. Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset") Cc: <[email protected]> # v4.17+ Cc: Torez Smith <[email protected]> Signed-off-by: Bill Kuzeja <[email protected]> Signed-off-by: Torez Smith <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04usb: xhci: wait for CNR controller not ready bit in xhci resumeRick Tseng1-0/+12
NVIDIA 3.1 xHCI card would lose power when moving power state into D3Cold. Thus we need to wait for CNR bit to clear in xhci resume, just as in xhci init. [Minor changes to comment and commit message -Mathias] Cc: <[email protected]> Signed-off-by: Rick Tseng <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04xhci: Fix USB 3.1 capability detection on early xHCI 1.1 spec based hostsMathias Nyman1-4/+11
Early xHCI 1.1 spec did not mention USB 3.1 capable hosts should set sbrn to 0x31, or that the minor revision is a two digit BCD containing minor and sub-minor numbers. This was later clarified in xHCI 1.2. Some USB 3.1 capable hosts therefore have sbrn set to 0x30, or minor revision set to 0x1 instead of 0x10. Detect the USB 3.1 capability correctly for these hosts as well Fixes: ddd57980a0fd ("xhci: detect USB 3.2 capable host controllers correctly") Cc: <[email protected]> # v4.18+ Cc: Loïc Yhuel <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04xhci: Check all endpoints for LPM timeoutJan Schmidt1-4/+4
If an endpoint is encountered that returns USB3_LPM_DEVICE_INITIATED, keep checking further endpoints, as there might be periodic endpoints later that return USB3_LPM_DISABLED due to shorter service intervals. Without this, the code can set too high a maximum-exit-latency and prevent the use of multiple USB3 cameras that should be able to work. Cc: <[email protected]> Signed-off-by: Jan Schmidt <[email protected]> Tested-by: Philipp Zabel <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04xhci: Prevent device initiated U1/U2 link pm if exit latency is too longMathias Nyman1-4/+6
If host/hub initiated link pm is prevented by a driver flag we still must ensure that periodic endpoints have longer service intervals than link pm exit latency before allowing device initiated link pm. Fix this by continue walking and checking endpoint service interval if xhci_get_timeout_no_hub_lpm() returns anything else than USB3_LPM_DISABLED While at it fix the split line error message Tested-by: Jan Schmidt <[email protected]> Cc: <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04xhci: Fix false warning message about wrong bounce buffer write lengthMathias Nyman1-2/+2
The check printing out the "WARN Wrong bounce buffer write length:" uses incorrect values when comparing bytes written from scatterlist to bounce buffer. Actual copied lengths are fine. The used seg->bounce_len will be set to equal new_buf_len a few lines later in the code, but is incorrect when doing the comparison. The patch which added this false warning was backported to 4.8+ kernels so this should be backported as far as well. Cc: <[email protected]> # v4.8+ Fixes: 597c56e372da ("xhci: update bounce buffer with correct sg num") Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04USB: host: ohci-at91: resume: balance the clock start callBoris Krasnovskiy1-2/+2
There is a clock enable counter run away problem in resume ohci_at91. Code enables clock that was never disabled in case of non wakeup interface. That would make clock unstoppable in future. Use proper alternative to start clocks only if they were stopped before. Signed-off-by: Boris Krasnovskiy <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04USB: host: ohci-at91: suspend: delay needed before to stop clocksNicolas Ferre1-0/+1
In order to completely remove marginal power consumption in PM suspend, we need to let the controller settle down before being stopped. In ohci_hcd_at91_drv_suspend() function, one additional delay is needed before to stop the clocks. Reported-by: Boris Krasnovskiy <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04USB: host: ohci-at91: completely shutdown the controller in at91_stop_hc()Boris Krasnovskiy1-1/+1
When removing the ohci-at91 module, the fact of not running complete shutdown of all the ports was keeping additional analog cells consuming power for no reason. Doing Reset (OHCI_HCR) to HcCommandStatus register is the way to go, but using the OHCI controller shutdown procedure is just perfect for this. Signed-off-by: Boris Krasnovskiy <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04usb: host: xhci-tegra: use regulator_bulk_set_supply_names()Bartosz Golaszewski1-2/+3
Use the new regulator helper instead of a for loop. Signed-off-by: Bartosz Golaszewski <[email protected]> Acked-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04usb: Fix Kconfig indentationKrzysztof Kozlowski1-34/+34
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04usb: host: u132-hcd: fix spelling mistake "overcurren" -> "overcurrent"Colin Ian King1-1/+1
There is a spelling mistake in a module parameter description. Fix it. Signed-off-by: Colin Ian King <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04usb: isp1362-hcd: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+2
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-04usb: host: xhci-tegra: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-5/+3
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-18Merge tag 'usb-5.4-rc1' of ↵Linus Torvalds65-4934/+574
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB updates from Greg KH: "Here is the big set of USB patches for 5.4-rc1. Two major chunks of code are moving out of the tree and into the staging directory, uwb and wusb (wireless USB support), because there are no devices that actually use this protocol anymore, and what we have today probably doesn't work at all given that the maintainers left many many years ago. So move it to staging where it will be removed in a few releases if no one screams. Other than that, lots of little things. The usual gadget and xhci and usb serial driver updates, along with a bunch of sysfs file cleanups due to the driver core changes to support that. Nothing really major, just constant forward progress. All of these have been in linux-next for a while with no reported issues" * tag 'usb-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (159 commits) USB: usbcore: Fix slab-out-of-bounds bug during device reset usb: cdns3: Remove redundant dev_err call in cdns3_probe() USB: rio500: Fix lockdep violation USB: rio500: simplify locking usb: mtu3: register a USB Role Switch for dual role mode usb: common: add USB GPIO based connection detection driver usb: common: create Kconfig file usb: roles: get usb-role-switch from parent usb: roles: Add fwnode_usb_role_switch_get() function device connection: Add fwnode_connection_find_match() usb: roles: Introduce stubs for the exiting functions in role.h dt-bindings: usb: mtu3: add properties about USB Role Switch dt-bindings: usb: add binding for USB GPIO based connection detection driver dt-bindings: connector: add optional properties for Type-B dt-binding: usb: add usb-role-switch property usbip: Implement SG support to vhci-hcd and stub driver usb: roles: intel: Enable static DRD mode for role switch xhci-ext-caps.c: Add property to disable Intel SW switch usb: dwc3: remove generic PHY calibrate() calls usb: core: phy: add support for PHY calibration ...
2019-09-16Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds2-8/+20
Pull ARM SoC platform updates from Arnd Bergmann: "The main change this time around is a cleanup of some of the oldest platforms based on the XScale and ARM9 CPU cores, which are between 10 and 20 years old. The Kendin/Micrel/Microchip KS8695, Winbond/Nuvoton W90x900 and Intel IOP33x/IOP13xx platforms are removed after we determined that nobody is using them any more. The TI Davinci and NXP LPC32xx platforms on the other hand are still in active use and are converted to the ARCH_MULTIPLATFORM build, meaning that we can compile a kernel that works on these along with most other ARMv5 platforms. Changes toward that goal are also merged for IOP32x, but additional work is needed to complete this. Patches for the remaining ARMv5 platforms have started but need more work and some testing. Support for the new ASpeed AST2600 gets added, this is based on the Cortex-A7 ARMv7 core, and is a newer version of the existing ARMv5 and ARMv6 chips in the same family. Other changes include a cleanup of the ST-Ericsson ux500 platform and the move of the TI Davinci platform to a new clocksource driver" [ The changes had marked INTEL_IOP_ADMA and USB_LPC32XX as being buildable on other platforms through COMPILE_TEST, but that causes new warnings that I most definitely do not want to see during the merge window as that could hide other issues. So the COMPILE_TEST option got disabled for them again - Linus ] * tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (61 commits) ARM: multi_v5_defconfig: make DaVinci part of the ARM v5 multiplatform build ARM: davinci: support multiplatform build for ARM v5 arm64: exynos: Enable exynos-chipid driver ARM: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init() ARM: OMAP2+: move platform-specific asm-offset.h to arch/arm/mach-omap2 ARM: davinci: dm646x: Fix a typo in the comment ARM: davinci: dm646x: switch to using the clocksource driver ARM: davinci: dm644x: switch to using the clocksource driver ARM: aspeed: Enable SMP boot ARM: aspeed: Add ASPEED AST2600 architecture ARM: aspeed: Select timer in each SoC dt-bindings: arm: cpus: Add ASPEED SMP ARM: imx: stop adjusting ar8031 phy tx delay mailmap: map old company name to new one @microchip.com MAINTAINERS: at91: remove the TC entry MAINTAINERS: at91: Collect all pinctrl/gpio drivers in same entry ARM: at91: move platform-specific asm-offset.h to arch/arm/mach-at91 MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers ARM: s3c64xx: squash samsung_usb_phy.h into setup-usb-phy.c ARM: debug-ll: Add support for r7s9210 ...
2019-09-03xhci-ext-caps.c: Add property to disable Intel SW switchSaranya Gopal1-0/+18
In platforms like Cherrytrail, 'SW switch enable' bit should not be enabled for role switch. This patch adds a property to Intel USB Role Switch platform driver to denote that SW switch should be disabled in Cherrytrail devices. Signed-off-by: Saranya Gopal <[email protected]> Signed-off-by: Balaji Manoharan <[email protected]> Suggested-by: Heikki Krogerus <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-03usb: host: xhci-rcar: Use xhci_plat_priv.quirks instead of code settingsYoshihiro Shimoda2-28/+14
This patch uses xhci_plat_priv.quirks to simplify. The previous code had conditions to set some quirks in xhci_rcar_init_quirk(). But, the xhci_rcar_init_quirk() is called at the same conditions. So, no behavior change. Signed-off-by: Yoshihiro Shimoda <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/1567425698-27560-4-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-03usb: host: xhci-rcar: Add a helper macro to set xhci_plat_privYoshihiro Shimoda2-8/+9
To avoid copy-and-paste setting of xhci_plat_priv for R-Car SoCs, this patch add a helper macro SET_XHCI_PLAT_PRIV_FOR_RCAR. Signed-off-by: Yoshihiro Shimoda <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/1567425698-27560-3-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-03usb: host: xhci-plat: add quirks member into struct xhci_plat_privYoshihiro Shimoda2-1/+5
To simplify adding xhci->quirks instead of the .init_quirk() function, this patch adds a new parameter "quirks" into the struct xhci_plat_priv. Signed-off-by: Yoshihiro Shimoda <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/1567425698-27560-2-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-03xhci: fix possible memleak on setup address fails.Ikjoon Jang1-1/+2
Xhci re-enables a slot on transaction error in set_address using xhci_disable_slot() + xhci_alloc_dev(). But in this case, xhci_alloc_dev() creates debugfs entries upon an existing device without cleaning up old entries, thus memory leaks. So this patch simply moves calling xhci_debugfs_free_dev() from xhci_free_dev() to xhci_disable_slot(). [added "possible" to header as this is about failure codepath -Mathias] Signed-off-by: Ikjoon Jang <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-03xhci: add TSP bitflag to TRB tracingMathias Nyman1-1/+2
Software can set a Transfer State Preserve (TSP) flag to maintain data toggle and sequence number when issuing a reset endpoint command. xhci driver is using TSP for soft retry, we want to show TSP usage in tracing as well Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-03usb: xhci: dbc: Use GFP_KERNEL instead of GFP_ATOMIC in ↵Christophe JAILLET1-1/+1
'xhci_dbc_alloc_requests()' There is no need to use GFP_ATOMIC to allocate 'req'. GFP_KERNEL should be enough and is already used for another allocation juste a few lines below. Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-03usb: xhci: dbc: Simplify error handling in 'xhci_dbc_alloc_requests()'Christophe JAILLET1-1/+1
If the 'kmalloc()' fails, we need to undo the previous 'dbc_alloc_request()' call. Because of the more similar function name, it is more logical to use 'dbc_free_request()' instead of 'xhci_dbc_free_req()'. Both are equivalent here because: static void xhci_dbc_free_req(struct dbc_ep *dep, struct dbc_request *req) { kfree(req->buf); dbc_free_request(dep, req); } and 'req->buf' is known to be NULL at this point Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-03usb/ohci-tmio: remove the HCD_DMA flagChristoph Hellwig1-1/+1
This driver doesn't support normal DMA, only direct access to its local memory. Remove the HCD_DMA flag to properly express that fact. Fixes: 7b81cb6bddd2 ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities") Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-03usb/ohci-sm501: remove the HCD_DMA flagChristoph Hellwig1-1/+1
This driver doesn't support normal DMA, only direct access to its local memory. Remove the HCD_DMA flag to properly express that fact. Fixes: 7b81cb6bddd2 ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities") Reported-by: Guenter Roeck <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Tested-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-09-02Merge 5.3-rc7 into usb-nextGreg Kroah-Hartman3-4/+23
We need the usb fixes in here for testing Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-28usb: xhci-mtk: add an optional xhci_ck clockChunfeng Yun2-0/+14
Some SoCs may have an optional clock xhci_ck (125M or 200M), it usually uses the same PLL as sys_ck, so support it. Signed-off-by: Chunfeng Yun <[email protected]> Acked-by: Mathias Nyman <[email protected]> Reviewed-by: Matthias Brugger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-28usb: host: xhci: rcar: Fix typo in compatible string matchingGeert Uytterhoeven1-1/+1
It's spelled "renesas", not "renensas". Due to this typo, RZ/G1M and RZ/G1N were not covered by the check. Fixes: 2dc240a3308b ("usb: host: xhci: rcar: retire use of xhci_plat_type_is()") Signed-off-by: Geert Uytterhoeven <[email protected]> Cc: stable <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-28usb: host: xhci-tegra: Set DMA mask correctlyNagarjuna Kristam1-0/+10
The Falcon microcontroller that runs the XUSB firmware and which is responsible for exposing the XHCI interface can address only 40 bits of memory. Typically that's not a problem because Tegra devices don't have enough system memory to exceed those 40 bits. However, if the ARM SMMU is enable on Tegra186 and later, the addresses passed to the XUSB controller can be anywhere in the 48-bit IOV address space of the ARM SMMU. Since the DMA/IOMMU API starts allocating from the top of the IOVA space, the Falcon microcontroller is not able to load the firmware successfully. Fix this by setting the DMA mask to 40 bits, which will force the DMA API to map the buffer for the firmware to an IOVA that is addressable by the Falcon. Signed-off-by: Nagarjuna Kristam <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-28usb: host: ohci: fix a race condition between shutdown and irqYoshihiro Shimoda1-3/+12
This patch fixes an issue that the following error is possible to happen when ohci hardware causes an interruption and the system is shutting down at the same time. [ 34.851754] usb 2-1: USB disconnect, device number 2 [ 35.166658] irq 156: nobody cared (try booting with the "irqpoll" option) [ 35.173445] CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 5.3.0-rc5 #85 [ 35.179964] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) [ 35.187886] Workqueue: usb_hub_wq hub_event [ 35.192063] Call trace: [ 35.194509] dump_backtrace+0x0/0x150 [ 35.198165] show_stack+0x14/0x20 [ 35.201475] dump_stack+0xa0/0xc4 [ 35.204785] __report_bad_irq+0x34/0xe8 [ 35.208614] note_interrupt+0x2cc/0x318 [ 35.212446] handle_irq_event_percpu+0x5c/0x88 [ 35.216883] handle_irq_event+0x48/0x78 [ 35.220712] handle_fasteoi_irq+0xb4/0x188 [ 35.224802] generic_handle_irq+0x24/0x38 [ 35.228804] __handle_domain_irq+0x5c/0xb0 [ 35.232893] gic_handle_irq+0x58/0xa8 [ 35.236548] el1_irq+0xb8/0x180 [ 35.239681] __do_softirq+0x94/0x23c [ 35.243253] irq_exit+0xd0/0xd8 [ 35.246387] __handle_domain_irq+0x60/0xb0 [ 35.250475] gic_handle_irq+0x58/0xa8 [ 35.254130] el1_irq+0xb8/0x180 [ 35.257268] kernfs_find_ns+0x5c/0x120 [ 35.261010] kernfs_find_and_get_ns+0x3c/0x60 [ 35.265361] sysfs_unmerge_group+0x20/0x68 [ 35.269454] dpm_sysfs_remove+0x2c/0x68 [ 35.273284] device_del+0x80/0x370 [ 35.276683] hid_destroy_device+0x28/0x60 [ 35.280686] usbhid_disconnect+0x4c/0x80 [ 35.284602] usb_unbind_interface+0x6c/0x268 [ 35.288867] device_release_driver_internal+0xe4/0x1b0 [ 35.293998] device_release_driver+0x14/0x20 [ 35.298261] bus_remove_device+0x110/0x128 [ 35.302350] device_del+0x148/0x370 [ 35.305832] usb_disable_device+0x8c/0x1d0 [ 35.309921] usb_disconnect+0xc8/0x2d0 [ 35.313663] hub_event+0x6e0/0x1128 [ 35.317146] process_one_work+0x1e0/0x320 [ 35.321148] worker_thread+0x40/0x450 [ 35.324805] kthread+0x124/0x128 [ 35.328027] ret_from_fork+0x10/0x18 [ 35.331594] handlers: [ 35.333862] [<0000000079300c1d>] usb_hcd_irq [ 35.338126] [<0000000079300c1d>] usb_hcd_irq [ 35.342389] Disabling IRQ #156 ohci_shutdown() disables all the interrupt and rh_state is set to OHCI_RH_HALTED. In other hand, ohci_irq() is possible to enable OHCI_INTR_SF and OHCI_INTR_MIE on ohci_irq(). Note that OHCI_INTR_SF is possible to be set by start_ed_unlink() which is called: ohci_irq() -> process_done_list() -> takeback_td() -> start_ed_unlink() So, ohci_irq() has the following condition, the issue happens by &ohci->regs->intrenable = OHCI_INTR_MIE | OHCI_INTR_SF and ohci->rh_state = OHCI_RH_HALTED: /* interrupt for some other device? */ if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED)) return IRQ_NOTMINE; To fix the issue, ohci_shutdown() holds the spin lock while disabling the interruption and changing the rh_state flag to prevent reenable the OHCI_INTR_MIE unexpectedly. Note that io_watchdog_func() also calls the ohci_shutdown() and it already held the spin lock, so that the patch makes a new function as _ohci_shutdown(). This patch is inspired by a Renesas R-Car Gen3 BSP patch from Tho Vu. Signed-off-by: Yoshihiro Shimoda <[email protected]> Cc: stable <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/1566877910-6020-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-21usb/max3421: remove the dummy {un,}map_urb_for_dma methodsChristoph Hellwig1-17/+0
Now that we have an explicit HCD_DMA flag, there is not need to override these methods. Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-21usb: add a HCD_DMA flag instead of guestimating DMA capabilitiesChristoph Hellwig26-48/+20
The usb core is the only major place in the kernel that checks for a non-NULL device dma_mask to see if a device is DMA capable. This is generally a bad idea, as all major busses always set up a DMA mask, even if the device is not DMA capable - in fact bus layers like PCI can't even know if a device is DMA capable at enumeration time. This leads to lots of workaround in HCD drivers, and also prevented us from setting up a DMA mask for platform devices by default last time we tried. Replace this guess with an explicit HCD_DMA that is set by drivers that appear to have DMA support. Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-21usb: host: ohci-pxa27x: Fix and & vs | typoDan Carpenter1-1/+1
The code is supposed to clear the RH_A_NPS and RH_A_PSM bits, but it's a no-op because of the & vs | typo. This bug predates git and it was only discovered using static analysis so it must not affect too many people in real life. Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/20190817065520.GA29951@mwanda Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-19Merge 5.3-rc5 into usb-nextGreg Kroah-Hartman1-0/+4
We need the usb fixes in here as well for other patches to build on. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-15usb: ohci-nxp: enable compile-testingArnd Bergmann2-8/+20
The driver hardcodes a hardware I/O address the way one should generally not do, and this prevents both compile-testing, and moving the platform to CONFIG_ARCH_MULTIPLATFORM. Change the code to be independent of the machine headers to allow those two. Removing the hardcoded address would be hard and is not necessary, so leave that in place for now. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-08-15usb: host: fotg2: restart hcd after port resetHans Ulli Kroll1-0/+4
On the Gemini SoC the FOTG2 stalls after port reset so restart the HCD after each port reset. Signed-off-by: Hans Ulli Kroll <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-12Merge 5.3-rc4 into usb-nextGreg Kroah-Hartman2-2/+17
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.