- 10 Oct, 2019 2 commits
-
-
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 <johan@kernel.org> Link: https://lore.kernel.org/r/20191009170944.30057-3-johan@kernel.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
Pawel Laszczak <pawell@cadence.com> Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver") Tested-by:
Roger Quadros <rogerq@ti.com> Link: https://lore.kernel.org/r/1570430355-26118-1-git-send-email-pawell@cadence.comSigned-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 34 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:
-
Johan Hovold authored
Replace the one remaining printk with pr_err(). Signed-off-by:
-
Johan Hovold authored
Drop the redundant lcd mutex introduced by commit 925ce689 ("USB: autoconvert trivial BKL users to private mutex") which replaced an earlier BKL use. The lock serialised calls to open() against other open() and a custom ioctl() returning the bcdDevice (sic!), but neither is needed. Signed-off-by:
-
Johan Hovold authored
Drop the redundant disconnect mutex which was introduced after the open-disconnect race had been addressed generally in USB core by commit d4ead16f ("USB: prevent char device open/deregister race"). Specifically, the rw-semaphore in core guarantees that all calls to open() will have completed and that no new calls to open() will occur after usb_deregister_dev() returns. Hence there is no need use the driver data as an inverted disconnected flag. Signed-off-by:
-
Johan Hovold authored
Make sure to stop all I/O on disconnect by adding a disconnected flag which is used to prevent new I/O from being started and by stopping all ongoing I/O before returning. This also fixes a potential use-after-free on driver unbind in case the driver data is freed before the completion handler has run. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> # 7bbe990cSigned-off-by:
-
Mauro Carvalho Chehab authored
Those files got renamed, but another DT file still points to the older places. Fixes: 87a55485 ("dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml") Fixes: da86d286 ("dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml") Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/9ca2d136a1f79c878fff1208f9b536b0b613c0d5.1569330078.git.mchehab+samsung@kernel.orgSigned-off-by:
-
Dan Carpenter authored
The "port->typec_caps.data" and "port->typec_caps.type" variables are enums and in this context GCC will treat them as an unsigned int so they can never be less than zero. Fixes: ae8a2ca8 ("usb: typec: Group all TCPCI/TCPM code together") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
-
Jacky.Cao@sony.com authored
The power budget for SuperSpeed mode should be 900 mA according to USB specification, so set the power budget to 900mA for dummy_start_ss which is only used for SuperSpeed mode. If the max power consumption of SuperSpeed device is larger than 500 mA, insufficient available bus power error happens in usb_choose_configuration function when the device connects to dummy hcd. Signed-off-by:
Jacky Cao <Jacky.Cao@sony.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/16EA1F625E922C43B00B9D82250220500871CDE5@APYOKXMS108.ap.sony.comSigned-off-by:
-
Mao Wenan authored
If the return value of vhci_init_attr_group and sysfs_create_group is non-zero, which mean they failed to init attr_group and create sysfs group, so it would better add 'failed' message to indicate that. This patch also change pr_err to dev_err to trace which device is failed. Fixes: 0775a9cb ("usbip: vhci extension: modifications to vhci driver") Signed-off-by:
Mao Wenan <maowenan@huawei.com> Acked-by:
Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20190916150921.152977-1-maowenan@huawei.comSigned-off-by:
-
Alan Stern authored
According to Greg KH, it has been generally agreed that when a USB driver encounters an unknown error (or one it can't handle directly), it should just give up instead of going into a potentially infinite retry loop. The three codes -EPROTO, -EILSEQ, and -ETIME fall into this category. They can be caused by bus errors such as packet loss or corruption, attempting to communicate with a disconnected device, or by malicious firmware. Nowadays the extent of packet loss or corruption is negligible, so it should be safe for a driver to give up whenever one of these errors occurs. Although the yurex driver handles -EILSEQ errors in this way, it doesn't do the same for -EPROTO (as discovered by the syzbot fuzzer) or other unrecognized errors. This patch adjusts the driver so that it doesn't log an error message for -EPROTO or -ETIME, and it doesn't retry after any errors. Reported-and-tested-by: syzbot+b24d736f18a1541ad550@syzkaller.appspotmail.com Signed-off-by:
-
