- 10 Oct, 2019 11 commits
-
-
Johan Hovold authored
A recent fix addressing a deadlock on disconnect introduced a new bug by moving the present flag out of the critical section protected by the driver-data mutex. This could lead to a racing release() freeing the driver data before disconnect() is done with it. Due to insufficient locking a related use-after-free could be triggered also before the above mentioned commit. Specifically, the driver needs to hold the driver-data mutex also while checking the opened flag at disconnect(). Fixes: c468a8aa ("usb: iowarrior: fix deadlock on disconnect") Fixes: 946b960d ("USB: add driver for iowarrior devices.") Cc: stable <stable@vger.kernel.org> # 2.6.21 Reported-by: syzbot+0761012cebf7bdb38137@syzkaller.appspotmail.com Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20191009104846.5925-2-johan@kernel.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
The driver was accessing its struct usb_interface in its release() callback without holding a reference. This would lead to a use-after-free whenever the device was disconnected while the character device was still open. Fixes: 66e3e591 ("usb: Add driver for Altus Metrum ChaosKey device (v2)") Cc: stable <stable@vger.kernel.org> # 4.1 Signed-off-by:
-
Johan Hovold authored
The driver was accessing its struct usb_device in its release() callback without holding a reference. This would lead to a use-after-free whenever the device was disconnected while the character device was still open. Fixes: 66d4bc30 ("USB: adutux: remove custom debug macro") Cc: stable <stable@vger.kernel.org> # 3.12 Signed-off-by:
-
Johan Hovold authored
The driver was using its struct usb_interface pointer as an inverted disconnected flag, but was setting it to NULL before making sure all completion handlers had run. This could lead to a NULL-pointer dereference in a number of dev_dbg, dev_warn and dev_err statements in the completion handlers which relies on said pointer. Fix this by unconditionally stopping all I/O and preventing resubmissions by poisoning the interrupt URBs at disconnect and using a dedicated disconnected flag. This also makes sure that all I/O has completed by the time the disconnect callback returns. Fixes: 2824bd25 ("[PATCH] USB: add ldusb driver") Cc: stable <stable@vger.kernel.org> # 2.6.13 Signed-off-by:
-
Johan Hovold authored
The driver was accessing its struct usb_device in its release() callback without holding a reference. This would lead to a use-after-free whenever the device was disconnected while the character device was still open. Fixes: fef526ca ("USB: legousbtower: remove custom debug macro") Cc: stable <stable@vger.kernel.org> # 3.12 Signed-off-by:
-
Pawel Laszczak authored
This patch restores the correct DMA mask after switching back to device mode. The issue occurred because Device part of controller use 32 bits DMA and Host side use 64 bits DMA. During loading XHCI driver the DMA mask used by driver is overwritten by XHCI driver so it must be restored to 32 bits. Reported-by:
Pawel Laszczak <pawell@cadence.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Peter Chen <peter.chen@nxp.com> Tested-by:
-
Roger Quadros authored
At startup we should trigger the HW state machine only if it is OTG mode. Otherwise we should just start the respective role. Initialize idle role by default. If we don't do this then cdns3_idle_role_stop() is not called when switching to host/device role and so lane switch mechanism doesn't work. This results to super-speed device not working in one orientation if it was plugged before driver probe. Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Link: https://lore.kernel.org/r/20191007121601.25996-2-rogerq@ti.comSigned-off-by:
-
Roger Quadros authored
We need to disable USB3 PHY for full-speed mode else gadget mode is broken. Signed-off-by:
-
Johan Hovold authored
The driver bails out at probe if we can't find a bulk-in endpoint or if we fail to allocate the URB, so drop the check in read(). Signed-off-by:
-
Johan Hovold authored
The driver failed to stop its read URB on disconnect, something which could lead to a use-after-free in the completion handler after driver unbind in case the character device has been closed. Fixes: e7389cc9 ("USB: skel_read really sucks royally") Signed-off-by:
-
Johan Hovold authored
The driver was using its struct usb_interface pointer as an inverted disconnected flag and was setting it to NULL before making sure all completion handlers had run. This could lead to NULL-pointer dereferences in the dev_err() statements in the completion handlers which relies on said pointer. Fix this by using a dedicated disconnected flag. Note that this is also addresses a NULL-pointer dereference at release() and a struct usb_interface reference leak introduced by a recent runtime PM fix, which depends on and should have been submitted together with this patch. Fixes: 4212cd74 ("USB: usb-skeleton.c: remove err() usage") Fixes: 5c290a5e ("USB: usb-skeleton: fix runtime PM after driver unbind") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
- 07 Oct, 2019 4 commits
-
-
Pawel Laszczak authored
Patch fixes issue with Halt Endnpoint Test observed during using g_zero driver as DUT. Bug occurred only on some testing board. Endpoint can defer transition to Halted state if endpoint has pending requests. Patch add additional condition that allows to return correct endpoint status during Get Endpoint Status request even if the halting endpoint is in progress. Reported-by:
Rahul Kumar <kurahul@cadence.com> Signed-off-by:
-
Hans de Goede authored
Since commit 7723f4c5 ("driver core: platform: Add an error message to platform_get_irq*()"), platform_get_irq() will call dev_err() itself on failure, so there is no need for the driver to also do this. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Link: https://lore.kernel.org/r/20191005210449.3926-4-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
The dwc3 code to get the "peripheral" / "host" / "otg" IRQ first tries platform_get_irq_byname() and then falls back to the IRQ at index 0 if the platform_get_irq_byname(). In this case we do not want platform_get_irq_byname() to print an error on failure, so switch to platform_get_irq_byname_optional() instead which does not print an error. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205037Signed-off-by:
-
Hans de Goede authored
Some drivers (e.g dwc3) first try to get an IRQ byname and then fall back to the one at index 0. In this case we do not want the error(s) printed by platform_get_irq_byname(). This commit adds a new platform_get_irq_byname_optional(), which does not print errors, for this. While at it also improve the kdoc text for platform_get_irq_byname() a bit. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205037Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20191005210449.3926-2-hdegoede@redhat.comSigned-off-by:
-
- 04 Oct, 2019 25 commits
-
-
Greg Kroah-Hartman authored
Merge tag 'usb-serial-5.4-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for 5.4-rc2 Here's a fix for a long-standing issue in the keyspan driver which could lead to NULL-pointer dereferences when a device had unexpected endpoint descriptors. Included are also some new device IDs. All but the last two commits have been in linux-next with no reported issues. Signed-off-by:
-
Johan Hovold authored
Since commit c2b71462 ("USB: core: Fix bug caused by duplicate interface PM usage counter") USB drivers must always balance their runtime PM gets and puts, including when the driver has already been unbound from the interface. Leaving the interface with a positive PM usage counter would prevent a later bound driver from suspending the device. Note that runtime PM has never actually been enabled for this driver since the support_autosuspend flag in its usb_driver struct is not set. Fixes: c2b71462 ("USB: core: Fix bug caused by duplicate interface PM usage counter") Cc: stable <stable@vger.kernel.org> Acked-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Johan Hovold authored
Since commit c2b71462 ("USB: core: Fix bug caused by duplicate interface PM usage counter") USB drivers must always balance their runtime PM gets and puts, including when the driver has already been unbound from the interface. Leaving the interface with a positive PM usage counter would prevent a later bound driver from suspending the device. Fixes: c2b71462 ("USB: core: Fix bug caused by duplicate interface PM usage counter") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Johan Hovold authored
Since commit c2b71462 ("USB: core: Fix bug caused by duplicate interface PM usage counter") USB drivers must always balance their runtime PM gets and puts, including when the driver has already been unbound from the interface. Leaving the interface with a positive PM usage counter would prevent a later bound driver from suspending the device. Fixes: c2b71462 ("USB: core: Fix bug caused by duplicate interface PM usage counter") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Johan Hovold authored
Since commit c2b71462 ("USB: core: Fix bug caused by duplicate interface PM usage counter") USB drivers must always balance their runtime PM gets and puts, including when the driver has already been unbound from the interface. Leaving the interface with a positive PM usage counter would prevent a later bound driver from suspending the device. Fixes: c2b71462 ("USB: core: Fix bug caused by duplicate interface PM usage counter") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Wei Yongjun authored
Add the missing platform_device_put() before return from xhci_create_intel_xhci_sw_pdev() in the error handling case. Fixes: 6ed151f2 ("xhci-ext-caps.c: Add property to disable Intel SW switch") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20190905100001.128349-1-weiyongjun1@huawei.comSigned-off-by:
-
Maxime Ripard authored
While the original bindings that were superseeded by the YAML schemas didn't mention that phy-names was needed, it turns out that phy-names is required if phys is set according to phy/phy-bindings.txt. Let's add back those properties. Fixes: 14ec072a ("dt-bindings: usb: Convert USB HCD generic binding to YAML") Fixes: c93bcace ("dt-bindings: usb: Convert the generic OHCI binding to YAML") Fixes: c3e2485d ("dt-bindings: usb: Convert the generic EHCI binding to YAML") Reported-by:
Emmanuel Vadot <manu@bidouilliste.com> Signed-off-by:
Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20191002112651.100504-2-mripard@kernel.orgSigned-off-by:
-
Maxime Ripard authored
This reverts commits 3d109bdc ("ARM: dts: sunxi: Remove useless phy-names from EHCI and OHCI"), 0a3df8bb ("ARM: dts: sunxi: h3/h5: Remove useless phy-names from EHCI and OHCI") and 3c7ab90a ("arm64: dts: allwinner: Remove useless phy-names from EHCI and OHCI"). It turns out that while the USB bindings were not mentionning it, the PHY client bindings were mandating that phy-names is set when phys is. Let's add it back. Fixes: 3d109bdc ("ARM: dts: sunxi: Remove useless phy-names from EHCI and OHCI") Fixes: 0a3df8bb ("ARM: dts: sunxi: h3/h5: Remove useless phy-names from EHCI and OHCI") Fixes: 3c7ab90a ("arm64: dts: allwinner: Remove useless phy-names from EHCI and OHCI") Reported-by:
-
Yoshihiro Shimoda authored
According to usb_ep_set_halt()'s description, __usbhsg_ep_set_halt_wedge() should return -EAGAIN if the IN endpoint has any queue or data. Otherwise, this driver is possible to cause just STALL without sending a short packet data on g_mass_storage driver, and then a few resetting a device happens on a host side during a usb enumaration. Fixes: 2f98382d ("usb: renesas_usbhs: Add Renesas USBHS Gadget") Cc: <stable@vger.kernel.org> # v3.0+ Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1569924633-322-3-git-send-email-yoshihiro.shimoda.uh@renesas.comSigned-off-by:
-
Yoshihiro Shimoda authored
The commit 97664a20 ("usb: renesas_usbhs: shrink spin lock area") had added a usbhsg_pipe_disable() calling into __usbhsg_ep_set_halt_wedge() accidentally. But, this driver should not call the usbhsg_pipe_disable() because the function discards all queues. So, this patch removes it. Fixes: 97664a20 ("usb: renesas_usbhs: shrink spin lock area") Cc: <stable@vger.kernel.org> # v3.1+ Signed-off-by:
-
Arnd Bergmann authored
gcc points out a suspicious cast from a pointer to an 'int' when compile-testing on 64-bit architectures. drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_pop_fifo’: drivers/usb/gadget/udc/lpc32xx_udc.c:1156:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_stuff_fifo’: drivers/usb/gadget/udc/lpc32xx_udc.c:1257:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] The code works find, but it's easy enough to change the cast to a uintptr_t to shut up that warning. Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20190918200201.2292008-1-arnd@arndb.deSigned-off-by:
-
Mathias Nyman authored
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: ef513be0 ("usb: xhci: Add Clear_TT_Buffer") Cc: <stable@vger.kernel.org> # v5.3 Reported-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1570190373-30684-9-git-send-email-mathias.nyman@linux.intel.comSigned-off-by:
-
Kai-Heng Feng authored
After commit f7fac17c ("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: f7fac17c ("xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()") Cc: <stable@vger.kernel.org> # v5.2+ Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Bill Kuzeja authored
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 f5249461 ("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: f5249461 ("xhci: Clear the host side toggle manually when endpoint is soft reset") Cc: <stable@vger.kernel.org> # v4.17+ Cc: Torez Smith <torez@redhat.com> Signed-off-by:
Bill Kuzeja <william.kuzeja@stratus.com> Signed-off-by:
Torez Smith <torez@redhat.com> Signed-off-by:
-
Rick Tseng authored
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: <stable@vger.kernel.org> Signed-off-by:
Rick Tseng <rtseng@nvidia.com> Signed-off-by:
-
Mathias Nyman authored
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: ddd57980 ("xhci: detect USB 3.2 capable host controllers correctly") Cc: <stable@vger.kernel.org> # v4.18+ Cc: Loïc Yhuel <loic.yhuel@gmail.com> Signed-off-by:
-
Jan Schmidt authored
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: <stable@vger.kernel.org> Signed-off-by:
Jan Schmidt <jan@centricular.com> Tested-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Mathias Nyman authored
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:
-
Mathias Nyman authored
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: <stable@vger.kernel.org> # v4.8+ Fixes: 597c56e3 ("xhci: update bounce buffer with correct sg num") Signed-off-by:
-
Johan Hovold authored
The driver would return with a nonzero open count in case the reset control request failed. This would prevent any further attempts to open the char dev until the device was disconnected. Fix this by incrementing the open count only on successful open. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Johan Hovold authored
The driver is using its struct usb_device pointer as an inverted disconnected flag, but was setting it to NULL before making sure all completion handlers had run. This could lead to a NULL-pointer dereference in a number of dev_dbg and dev_err statements in the completion handlers which relies on said pointer. Fix this by unconditionally stopping all I/O and preventing resubmissions by poisoning the interrupt URBs at disconnect and using a dedicated disconnected flag. This also makes sure that all I/O has completed by the time the disconnect callback returns. Fixes: 9d974b2a ("USB: legousbtower.c: remove err() usage") Fixes: fef526ca ("USB: legousbtower: remove custom debug macro") Fixes: 4dae9963 ("USB: legotower: remove custom debug macro and module parameter") Cc: stable <stable@vger.kernel.org> # 3.5 Signed-off-by:
-
Johan Hovold authored
Fix a potential deadlock if disconnect races with open. Since commit d4ead16f ("USB: prevent char device open/deregister race") core holds an rw-semaphore while open is called and when releasing the minor number during deregistration. This can lead to an ABBA deadlock if a driver takes a lock in open which it also holds during deregistration. This effectively reverts commit 78663ecc ("USB: disconnect open race in legousbtower") which needlessly introduced this issue after a generic fix for this race had been added to core by commit d4ead16f ("USB: prevent char device open/deregister race"). Fixes: 78663ecc ("USB: disconnect open race in legousbtower") Cc: stable <stable@vger.kernel.org> # 2.6.24 Reported-by: syzbot+f9549f5ee8a5416f0b95@syzkaller.appspotmail.com Tested-by: syzbot+f9549f5ee8a5416f0b95@syzkaller.appspotmail.com Signed-off-by:
-
Johan Hovold authored
Make sure to check for short transfers when retrieving the version information at probe to avoid leaking uninitialised slab data when logging it. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Heikki Krogerus authored
Making sure that ucsi_displayport_enter() function does not return an error if the displayport alternate mode has already been entered. It's normal that the firmware (or controller) has already entered the alternate mode by the time the operating system is notified about the device. Fixes: af8622f6 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20191004100219.71152-3-heikki.krogerus@linux.intel.comSigned-off-by:
-
Heikki Krogerus authored
The "run_isr" flag is used for preventing the driver from calling the interrupt service routine in its runtime resume callback when the driver is expecting completion to a command, but what that basically does is that it hides the real problem. The real problem is that the controller is allowed to suspend in the middle of command execution. As a more appropriate fix for the problem, using autosuspend delay time that matches UCSI_TIMEOUT_MS (5s). That prevents the controller from suspending while still in the middle of executing a command. This fixes a potential deadlock. Both ccg_read() and ccg_write() are called with the mutex already taken at least from ccg_send_command(). In ccg_read() and ccg_write, the mutex is only acquired so that run_isr flag can be set. Fixes: f0e4cd94 ("usb: typec: ucsi: ccg: add runtime pm workaround") Cc: stable@vger.kernel.org Signed-off-by:
-
