aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb/core
AgeCommit message (Collapse)AuthorFilesLines
2020-07-21usb: core: fix quirks_param_set() writing to a const pointerKars Mulder1-4/+12
The function quirks_param_set() takes as argument a const char* pointer to the new value of the usbcore.quirks parameter. It then casts this pointer to a non-const char* pointer and passes it to the strsep() function, which overwrites the value. Fix this by creating a copy of the value using kstrdup() and letting that copy be written to by strsep(). Fixes: 027bd6cafd9a ("usb: core: Add "quirks" parameter for usbcore") Signed-off-by: Kars Mulder <[email protected]> Link: https://lore.kernel.org/r/5ee2-5f048a00-21-618c5c00@230659773 Signed-off-by: Greg Kroah-Hartman <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-10usb: Use fallthrough pseudo-keywordGustavo A. R. Silva4-8/+8
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/20200707195607.GA4198@embeddedor Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-09usb: core: ledtrig-usbport: Demote obvious misuse of kerneldoc to standard ↵Lee Jones1-3/+3
comment blocks No attempt has been made to document any of the functions here. Fixes the following W=1 kernel build warning(s): drivers/usb/core/ledtrig-usbport.c:42: warning: Function parameter or member 'usbport_data' not described in 'usbport_trig_usb_dev_observed' drivers/usb/core/ledtrig-usbport.c:42: warning: Function parameter or member 'usb_dev' not described in 'usbport_trig_usb_dev_observed' drivers/usb/core/ledtrig-usbport.c:71: warning: Function parameter or member 'usbport_data' not described in 'usbport_trig_update_count' drivers/usb/core/ledtrig-usbport.c:131: warning: Function parameter or member 'usbport_data' not described in 'usbport_trig_port_observed' drivers/usb/core/ledtrig-usbport.c:131: warning: Function parameter or member 'usb_dev' not described in 'usbport_trig_port_observed' drivers/usb/core/ledtrig-usbport.c:131: warning: Function parameter or member 'port1' not described in 'usbport_trig_port_observed' Cc: Rafał Miłecki <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-01USB: Fix up terminologyGreg Kroah-Hartman1-3/+2
USB is a HOST/DEVICE protocol, as per the specification and all documentation. Fix up terms that are not applicable to make things match up with the terms used through the rest of the USB stack. Signed-off-by: Greg Kroah-Hartman <[email protected]> Acked-by: Felipe Balbi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-06-29Merge 5.8-rc3 into usb-nextGreg Kroah-Hartman1-1/+2
We want the USB fixes in here, and this resolves a merge issue found in linux-next. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-06-19USB: OTG: rename product list of devicesGreg Kroah-Hartman3-14/+10
Rename the list of specific devices that an OTG device could support to make it more obvious as to what this list is for and what it is doing. Also rename the configuration option to make it more obvious as well. Cc: Thomas Bogendoerfer <[email protected]> Cc: Paul Burton <[email protected]> Cc: "Diego Elio Pettenò" <[email protected]> Cc: "Martin K. Petersen" <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Jiaxun Yang <[email protected]> Cc: Krzysztof Kozlowski <[email protected]> Cc: "Philippe Mathieu-Daudé" <[email protected]> Cc: Alan Stern <[email protected]> Cc: Eugeniu Rosca <[email protected]> Cc: Qi Zhou <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Hardik Gajjar <[email protected]> Cc: Harry Pan <[email protected]> Cc: David Heinzelmann <[email protected]> Cc: Nishad Kamdar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-06-19USB: rename USB OTG hub configuration optionGreg Kroah-Hartman2-2/+2
The USB OTG code has the ability to disable external hubs, but the configuration option for it is oddly named. Rename it to be more obvious as to what it does. Cc: Thomas Bogendoerfer <[email protected]> Cc: Bin Liu <[email protected]> Cc: Paul Cercueil <[email protected]> Cc: Alan Stern <[email protected]> Cc: Eugeniu Rosca <[email protected]> Cc: Kai-Heng Feng <[email protected]> Cc: David Heinzelmann <[email protected]> Cc: "Lee, Chiasheng" <[email protected]> Cc: Keiya Nobuta <[email protected]> Cc: Hardik Gajjar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-06-19USB: rename USB quirk to USB_QUIRK_ENDPOINT_IGNOREGreg Kroah-Hartman3-14/+14
The USB core has a quirk flag to ignore specific endpoints, so rename it to be more obvious what this quirk does. Cc: Johan Hovold <[email protected]> Cc: Alan Stern <[email protected]> Cc: Richard Dodd <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Jonathan Cox <[email protected]> Cc: Bastien Nocera <[email protected]> Cc: "Thiébaud Weksteen" <[email protected]> Cc: Nishad Kamdar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-06-18usb: add USB_QUIRK_DELAY_INIT for Logitech C922Tomasz Meresiński1-1/+2
The Logitech C922, just like other Logitech webcams, needs the USB_QUIRK_DELAY_INIT or it will randomly not respond after device connection Signed-off-by: Tomasz Meresiński <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-06-18drivers: usb: Fix trivial spellingKieran Bingham1-1/+1
The word 'descriptor' is misspelled throughout the tree. Fix it up accordingly: decriptors -> descriptors Signed-off-by: Kieran Bingham <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-06-18USB: core: additional Device Classes to debug/usb/devicesRob Gill1-0/+4
Several newer USB Device classes are not presently reported individually at /sys/kernel/debug/usb/devices, (reported as "unk."). This patch adds the following classes: 0fh (Personal Healthcare devices), 10h (USB Type-C combined Audio/Video devices) 11h (USB billboard), 12h (USB Type-C Bridge). As defined at [https://www.usb.org/defined-class-codes] Corresponding classes defined in include/linux/usb/ch9.h. Signed-off-by: Rob Gill <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-06-07Merge tag 'usb-5.8-rc1' of ↵Linus Torvalds6-9/+12
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB/PHY driver updates from Greg KH: "Here are the large set of USB and PHY driver updates for 5.8-rc1. Nothing huge, just lots of little things: - USB gadget fixes and additions all over the place - new PHY drivers - PHY driver fixes and updates - XHCI driver updates - musb driver updates - more USB-serial driver ids added - various USB quirks added - thunderbolt minor updates and fixes - typec updates and additions All of these have been in linux-next for a while with no reported issues" * tag 'usb-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (245 commits) usb: dwc3: meson-g12a: fix USB2 PHY initialization on G12A and A1 SoCs usb: dwc3: meson-g12a: fix error path when fetching the reset line fails Revert "dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings" Revert "dt-bindings: usb: qcom,dwc3: Add compatible for SC7180" Revert "dt-bindings: usb: qcom,dwc3: Introduce interconnect properties for Qualcomm DWC3 driver" USB: serial: ch341: fix lockup of devices with limited prescaler USB: serial: ch341: add basis for quirk detection CDC-ACM: heed quirk also in error handling USB: serial: option: add Telit LE910C1-EUX compositions usb: musb: Fix runtime PM imbalance on error usb: musb: jz4740: Prevent lockup when CONFIG_SMP is set usb: musb: mediatek: add reset FADDR to zero in reset interrupt handle usb: musb: use true for 'use_dma' usb: musb: start session in resume for host port usb: musb: return -ESHUTDOWN in urb when three-strikes error happened USB: serial: qcserial: add DW5816e QDL support thunderbolt: Add trivial .shutdown usb: dwc3: keystone: Turn on USB3 PHY before controller dt-bindings: usb: ti,keystone-dwc3.yaml: Add USB3.0 PHY property dt-bindings: usb: convert keystone-usb.txt to YAML ...
2020-06-04usb: core: kcov: collect coverage from usb complete callbackAndrey Konovalov1-0/+3
This patch adds kcov_remote_start/stop() callbacks around the urb complete() callback that is executed in softirq context when dummy_hcd is in use. As the result, kcov can be used to collect coverage from those callbacks, which is used to facilitate coverage-guided fuzzing with syzkaller. Signed-off-by: Andrey Konovalov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Dmitry Vyukov <[email protected]> Cc: Alan Stern <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Marco Elver <[email protected]> Link: http://lkml.kernel.org/r/4520671eeb604adbc2432c248b0c07fbaa5519ef.1585233617.git.andreyknvl@google.com Link: http://lkml.kernel.org/r/2821d497ac1cdc0efb5e00df30271e4a67fc8009.1584655448.git.andreyknvl@google.com Signed-off-by: Linus Torvalds <[email protected]>
2020-06-01Merge branch 'uaccess.access_ok' of ↵Linus Torvalds2-11/+0
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull uaccess/access_ok updates from Al Viro: "Removals of trivially pointless access_ok() calls. Note: the fiemap stuff was removed from the series, since they are duplicates with part of ext4 series carried in Ted's tree" * 'uaccess.access_ok' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: vmci_host: get rid of pointless access_ok() hfi1: get rid of pointless access_ok() usb: get rid of pointless access_ok() calls lpfc_debugfs: get rid of pointless access_ok() efi_test: get rid of pointless access_ok() drm_read(): get rid of pointless access_ok() via-pmu: don't bother with access_ok() drivers/crypto/ccp/sev-dev.c: get rid of pointless access_ok() omapfb: get rid of pointless access_ok() calls amifb: get rid of pointless access_ok() calls drivers/fpga/dfl-afu-dma-region.c: get rid of pointless access_ok() drivers/fpga/dfl-fme-pr.c: get rid of pointless access_ok() cm4000_cs.c cmm_ioctl(): get rid of pointless access_ok() nvram: drop useless access_ok() n_hdlc_tty_read(): remove pointless access_ok() tomoyo_write_control(): get rid of pointless access_ok() btrfs_ioctl_send(): don't bother with access_ok() fat_dir_ioctl(): hadn't needed that access_ok() for more than a decade... dlmfs_file_write(): get rid of pointless access_ok()
2020-05-29usb: get rid of pointless access_ok() callsAl Viro2-11/+0
in all affected cases addresses are passed only to copy_from()_user or copy_to_user(). Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Al Viro <[email protected]>
2020-05-18Merge 5.7-rc6 into usb-nextGreg Kroah-Hartman2-4/+18
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
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 <[email protected]> Acked-by: Alan Stern <[email protected]> Acked-by: Mathias Nyman <[email protected]> Signed-off-by: Vinod Koul <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-15usb: core: hub: limit HUB_QUIRK_DISABLE_AUTOSUSPEND to USB5534BEugeniu Rosca1-1/+5
On Tue, May 12, 2020 at 09:36:07PM +0800, Kai-Heng Feng wrote [1]: > This patch prevents my Raven Ridge xHCI from getting runtime suspend. The problem described in v5.6 commit 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") applies solely to the USB5534B hub [2] present on the Kingfisher Infotainment Carrier Board, manufactured by Shimafuji Electric Inc [3]. Despite that, the aforementioned commit applied the quirk to _all_ hubs carrying vendor ID 0x424 (i.e. SMSC), of which there are more [4] than initially expected. Consequently, the quirk is now enabled on platforms carrying SMSC/Microchip hub models which potentially don't exhibit the original issue. To avoid reports like [1], further limit the quirk's scope to USB5534B [2], by employing both Vendor and Product ID checks. Tested on H3ULCB + Kingfisher rev. M05. [1] https://lore.kernel.org/linux-renesas-soc/[email protected]/ [2] https://www.microchip.com/wwwproducts/en/USB5534B [3] http://www.shimafuji.co.jp/wp/wp-content/uploads/2018/08/SBEV-RCAR-KF-M06Board_HWSpecificationEN_Rev130.pdf [4] https://devicehunt.com/search/type/usb/vendor/0424/device/any Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: [email protected] # v4.14+ Cc: Alan Stern <[email protected]> Cc: Hardik Gajjar <[email protected]> Cc: [email protected] Cc: [email protected] Reported-by: Kai-Heng Feng <[email protected]> Signed-off-by: Eugeniu Rosca <[email protected]> Tested-by: Kai-Heng Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-14USB: usbfs: fix mmap dma mismatchGreg Kroah-Hartman1-3/+13
In commit 2bef9aed6f0e ("usb: usbfs: correct kernel->user page attribute mismatch") we switched from always calling remap_pfn_range() to call dma_mmap_coherent() to handle issues with systems with non-coherent USB host controller drivers. Unfortunatly, as syzbot quickly told us, not all the world is host controllers with DMA support, so we need to check what host controller we are attempting to talk to before doing this type of allocation. Thanks to Christoph for the quick idea of how to fix this. Fixes: 2bef9aed6f0e ("usb: usbfs: correct kernel->user page attribute mismatch") Cc: Christoph Hellwig <[email protected]> Cc: Hillf Danton <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Jeremy Linton <[email protected]> Cc: stable <[email protected]> Reported-by: [email protected] Reviewed-by: Jeremy Linton <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-11Merge 5.7-rc5 into usb-nextGreg Kroah-Hartman2-5/+4
We want the USB fixes in here too. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-05usb: usbfs: correct kernel->user page attribute mismatchJeremy Linton1-3/+2
On some architectures (e.g. arm64) requests for IO coherent memory may use non-cachable attributes if the relevant device isn't cache coherent. If these pages are then remapped into userspace as cacheable, they may not be coherent with the non-cacheable mappings. In particular this happens with libusb, when it attempts to create zero-copy buffers for use by rtl-sdr (https://github.com/osmocom/rtl-sdr/). On low end arm devices with non-coherent USB ports, the application will be unexpectedly killed, while continuing to work fine on arm machines with coherent USB controllers. This bug has been discovered/reported a few times over the last few years. In the case of rtl-sdr a compile time option to enable/disable zero copy was implemented to work around it. Rather than relaying on application specific workarounds, dma_mmap_coherent() can be used instead of remap_pfn_range(). The page cache/etc attributes will then be correctly set in userspace to match the kernel mapping. Signed-off-by: Jeremy Linton <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-05USB: core: Fix misleading driver bug reportAlan Stern1-2/+2
The syzbot fuzzer found a race between URB submission to endpoint 0 and device reset. Namely, during the reset we call usb_ep0_reinit() because the characteristics of ep0 may have changed (if the reset follows a firmware update, for example). While usb_ep0_reinit() is running there is a brief period during which the pointers stored in udev->ep_in[0] and udev->ep_out[0] are set to NULL, and if an URB is submitted to ep0 during that period, usb_urb_ep_type_check() will report it as a driver bug. In the absence of those pointers, the routine thinks that the endpoint doesn't exist. The log message looks like this: ------------[ cut here ]------------ usb 2-1: BOGUS urb xfer, pipe 2 != type 2 WARNING: CPU: 0 PID: 9241 at drivers/usb/core/urb.c:478 usb_submit_urb+0x1188/0x1460 drivers/usb/core/urb.c:478 Now, although submitting an URB while the device is being reset is a questionable thing to do, it shouldn't count as a driver bug as severe as submitting an URB for an endpoint that doesn't exist. Indeed, endpoint 0 always exists, even while the device is in its unconfigured state. To prevent these misleading driver bug reports, this patch updates usb_disable_endpoint() to avoid clearing the ep_in[] and ep_out[] pointers when the endpoint being disabled is ep0. There's no danger of leaving a stale pointer in place, because the usb_host_endpoint structure being pointed to is stored permanently in udev->ep0; it doesn't get deallocated until the entire usb_device structure does. Reported-and-tested-by: [email protected] Signed-off-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28usb: core: hub: use true,false for bool variableJason Yan1-1/+1
Fix the following coccicheck warning: drivers/usb/core/hub.c:95:12-28: WARNING: Assignment of 0/1 to bool variable Signed-off-by: Jason Yan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-27Merge 5.7-rc3 into usb-nextGreg Kroah-Hartman3-4/+27
We need the USB fixes in here too. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-23USB: core: Replace an empty statement with a debug messageAlan Stern1-2/+4
This patch adds a dev_dbg() message to usb_create_sysfs_intf_files(). The message is not expected ever to appear; it's real purpose is to satisfy the __must_check attribute on device_create_file() without triggering a compiler warning about an empty statement. In fact we don't really care if the sysfs attribute file doesn't get created. The interface string descriptor is purely informational and hardly ever present. Suggested-by: NeilBrown <[email protected]> Signed-off-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-23USB: hub: Revert commit bd0e6c9614b9 ("usb: hub: try old enumeration scheme ↵Alan Stern1-3/+1
first for high speed devices") Commit bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") changed the way the hub driver enumerates high-speed devices. Instead of using the "new" enumeration scheme first and switching to the "old" scheme if that doesn't work, we start with the "old" scheme. In theory this is better because the "old" scheme is slightly faster -- it involves resetting the device only once instead of twice. However, for a long time Windows used only the "new" scheme. Zeng Tao said that Windows 8 and later use the "old" scheme for high-speed devices, but apparently there are some devices that don't like it. William Bader reports that the Ricoh webcam built into his Sony Vaio laptop not only doesn't enumerate under the "old" scheme, it gets hung up so badly that it won't then enumerate under the "new" scheme! Only a cold reset will fix it. Therefore we will revert the commit and go back to trying the "new" scheme first for high-speed devices. Reported-and-tested-by: William Bader <[email protected]> Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207219 Signed-off-by: Alan Stern <[email protected]> Fixes: bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") CC: Zeng Tao <[email protected]> CC: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-23USB: hub: Fix handling of connect changes during sleepAlan Stern1-0/+14
Commit 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") wasn't very well conceived. The problem it tried to fix was that if a connect-change event occurred while the system was asleep (such as a device disconnecting itself from the bus when it is suspended and then reconnecting when it resumes) requiring a reset-resume during the system wakeup transition, the hub port's change_bit entry would remain set afterward. This would cause the hub driver to believe another connect-change event had occurred after the reset-resume, which was wrong and would lead the driver to send unnecessary requests to the device (which could interfere with a firmware update). The commit tried to fix this by not setting the change_bit during the wakeup. But this was the wrong thing to do; it means that when a device is unplugged while the system is asleep, the hub driver doesn't realize anything has happened: The change_bit flag which would tell it to handle the disconnect event is clear. The commit needs to be reverted and the problem fixed in a different way. Fortunately an alternative solution was noted in the commit's Changelog: We can continue to set the change_bit entry in hub_activate() but then clear it when a reset-resume occurs. That way the the hub driver will see the change_bit when a device is disconnected but won't see it when the device is still present. That's what this patch does. Reported-and-tested-by: Peter Chen <[email protected]> Signed-off-by: Alan Stern <[email protected]> Fixes: 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") Tested-by: Paul Zimmerman <[email protected]> CC: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-16USB: Add USB_QUIRK_DELAY_CTRL_MSG and USB_QUIRK_DELAY_INIT for Corsair K70 ↵Jonathan Cox1-0/+4
RGB RAPIDFIRE The Corsair K70 RGB RAPIDFIRE needs the USB_QUIRK_DELAY_INIT and USB_QUIRK_DELAY_CTRL_MSG to function or it will randomly not respond on boot, just like other Corsair keyboards Signed-off-by: Jonathan Cox <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-16USB: core: Fix free-while-in-use bug in the USB S-GlibraryAlan Stern1-1/+8
FuzzUSB (a variant of syzkaller) found a free-while-still-in-use bug in the USB scatter-gather library: BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607 Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27 CPU: 1 PID: 27 Comm: kworker/u4:1 Not tainted 5.5.11 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: scsi_tmf_2 scmd_eh_abort_handler Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374 __kasan_report+0x153/0x1cb mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x152/0x1b0 mm/kasan/generic.c:192 __kasan_check_read+0x11/0x20 mm/kasan/common.c:95 atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607 usb_unlink_urb+0x72/0xb0 drivers/usb/core/urb.c:657 usb_sg_cancel+0x14e/0x290 drivers/usb/core/message.c:602 usb_stor_stop_transport+0x5e/0xa0 drivers/usb/storage/transport.c:937 This bug occurs when cancellation of the S-G transfer races with transfer completion. When that happens, usb_sg_cancel() may continue to access the transfer's URBs after usb_sg_wait() has freed them. The bug is caused by the fact that usb_sg_cancel() does not take any sort of reference to the transfer, and so there is nothing to prevent the URBs from being deallocated while the routine is trying to use them. The fix is to take such a reference by incrementing the transfer's io->count field while the cancellation is in progres and decrementing it afterward. The transfer's URBs are not deallocated until io->complete is triggered, which happens when io->count reaches zero. Signed-off-by: Alan Stern <[email protected]> Reported-and-tested-by: Kyungtae Kim <[email protected]> CC: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-16USB: core: Use the correct style for SPDX License IdentifierNishad Kamdar3-3/+3
This patch corrects the SPDX License Identifier style in header files related to USB Core. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used). Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46. Suggested-by: Joe Perches <[email protected]> Signed-off-by: Nishad Kamdar <[email protected]> Link: https://lore.kernel.org/r/20200328091844.GA3648@nishad Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-24usb: core: Add ACPI support for USB interface devicesAndy Shevchenko1-0/+2
Currently on ACPI-enabled systems the USB interface device has no link to the actual firmware node and thus drivers may not parse additional information given in the table. The new feature, proposed here, allows to pass properties or other information to the drivers. The ACPI companion of the device has to be set for USB interface devices to achieve above. Use ACPI_COMPANION_SET macro to set this. Note, OF already does link of_node and this is the same for ACPI case. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-23Merge 5.6-rc7 into usb-nextGreg Kroah-Hartman1-0/+6
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-17usb: quirks: add NO_LPM quirk for RTL8153 based ethernet adaptersHans de Goede1-0/+3
We have been receiving bug reports that ethernet connections over RTL8153 based ethernet adapters stops working after a while with errors like these showing up in dmesg when the ethernet stops working: [12696.189484] r8152 6-1:1.0 enp10s0u1: Tx timeout [12702.333456] r8152 6-1:1.0 enp10s0u1: Tx timeout [12707.965422] r8152 6-1:1.0 enp10s0u1: Tx timeout This has been reported on Dell WD15 docks, Belkin USB-C Express Dock 3.1 docks and with generic USB to ethernet dongles using the RTL8153 chipsets. Some users have tried adding usbcore.quirks=0bda:8153:k to the kernel commandline and all users who have tried this report that this fixes this. Also note that we already have an existing NO_LPM quirk for the RTL8153 used in the Microsoft Surface Dock (where it uses a different usb-id). This commit adds a NO_LPM quirk for the generic Realtek RTL8153 0bda:8153 usb-id, fixing the Tx timeout errors on these devices. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198931 Cc: [email protected] Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-12USB: Disable LPM on WD19's Realtek HubKai-Heng Feng1-0/+3
Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the bus when bringing underlying ports from U3 to U0. Disabling LPM on the hub during setting link state is not enough, so let's disable LPM completely for this hub. Acked-by: Alan Stern <[email protected]> Signed-off-by: Kai-Heng Feng <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-10Merge 5.6-rc5 into usb-nextGreg Kroah-Hartman3-4/+17
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-04usb: core: port: do error out if usb_autopm_get_interface() failsEugeniu Rosca1-2/+8
Reviewing a fresh portion of coverity defects in USB core (specifically CID 1458999), Alan Stern noted below in [1]: On Tue, Feb 25, 2020 at 02:39:23PM -0500, Alan Stern wrote: > A revised search finds line 997 in drivers/usb/core/hub.c and lines > 216, 269 in drivers/usb/core/port.c. (I didn't try looking in any > other directories.) AFAICT all three of these should check the > return value, although a error message in the kernel log probably > isn't needed. Factor out the usb_port_runtime_{resume,suspend}() changes into a standalone patch to allow conflict-free porting on top of stable v3.9+. [1] https://lore.kernel.org/lkml/[email protected] Fixes: 971fcd492cebf5 ("usb: add runtime pm support for usb port device") Cc: [email protected] # v3.9+ Suggested-by: Alan Stern <[email protected]> Signed-off-by: Eugeniu Rosca <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-04usb: core: hub: do error out if usb_autopm_get_interface() failsEugeniu Rosca1-1/+5
Reviewing a fresh portion of coverity defects in USB core (specifically CID 1458999), Alan Stern noted below in [1]: On Tue, Feb 25, 2020 at 02:39:23PM -0500, Alan Stern wrote: > A revised search finds line 997 in drivers/usb/core/hub.c and lines > 216, 269 in drivers/usb/core/port.c. (I didn't try looking in any > other directories.) AFAICT all three of these should check the > return value, although a error message in the kernel log probably > isn't needed. Factor out the usb_remove_device() change into a standalone patch to allow conflict-free integration on top of the earliest stable branches. [1] https://lore.kernel.org/lkml/[email protected] Fixes: 253e05724f9230 ("USB: add a "remove hardware" sysfs attribute") Cc: [email protected] # v2.6.33+ Suggested-by: Alan Stern <[email protected]> Signed-off-by: Eugeniu Rosca <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-04usb: core: hub: fix unhandled return by employing a void functionEugeniu Rosca1-1/+1
Address below Coverity complaint (Feb 25, 2020, 8:06 AM CET): *** CID 1458999: Error handling issues (CHECKED_RETURN) /drivers/usb/core/hub.c: 1869 in hub_probe() 1863 1864 if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND) 1865 hub->quirk_check_port_auto_suspend = 1; 1866 1867 if (id->driver_info & HUB_QUIRK_DISABLE_AUTOSUSPEND) { 1868 hub->quirk_disable_autosuspend = 1; >>> CID 1458999: Error handling issues (CHECKED_RETURN) >>> Calling "usb_autopm_get_interface" without checking return value (as is done elsewhere 97 out of 111 times). 1869 usb_autopm_get_interface(intf); 1870 } 1871 1872 if (hub_configure(hub, &desc->endpoint[0].desc) >= 0) 1873 return 0; 1874 Rather than checking the return value of 'usb_autopm_get_interface()', switch to the usb_autopm_get_interface_no_resume() API, as per: On Tue, Feb 25, 2020 at 10:32:32AM -0500, Alan Stern wrote: ------ 8< ------ > This change (i.e. 'ret = usb_autopm_get_interface') is not necessary, > because the resume operation cannot fail at this point (interfaces > are always powered-up during probe). A better solution would be to > call usb_autopm_get_interface_no_resume() instead. ------ 8< ------ Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: Hardik Gajjar <[email protected]> Cc: [email protected] # v4.14+ Reported-by: [email protected] Suggested-by: Alan Stern <[email protected]> Signed-off-by: Eugeniu Rosca <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-04usb: quirks: add NO_LPM quirk for Logitech Screen ShareDan Lazewatsky1-0/+3
LPM on the device appears to cause xHCI host controllers to claim that there isn't enough bandwidth to support additional devices. Signed-off-by: Dan Lazewatsky <[email protected]> Cc: stable <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-24Merge 5.6-rc3 into usb-nextGreg Kroah-Hartman5-17/+78
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-19usb: core: Use ACPI_SUCCESS() at appropriate placesAndy Shevchenko1-1/+1
Use ACPI_SUCCESS() to replace !ACPI_FAILURE(), this avoids additional operation. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-19usb: core: Make use of acpi_evaluate_object() statusAndy Shevchenko1-4/+5
Compiler is not happy about dangling variable: .../core/usb-acpi.c: In function ‘usb_acpi_get_connect_type’: .../core/usb-acpi.c:90:14: warning: variable ‘status’ set but not used [-Wunused-but-set-variable] 90 | acpi_status status; | ^~~~~~ Make use of it by checking the status and bail out in case of error. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-14usb: use kobj_to_dev() APIchenqiwu1-3/+3
Use kobj_to_dev() API instead of container_of(). Signed-off-by: chenqiwu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-12USB: Fallback to generic driver when specific driver failsBastien Nocera2-1/+7
If ->probe fails for a device specific driver, ask the driver core to reprobe us, after having flagged the device for the generic driver to be forced. Signed-off-by: Bastien Nocera <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-12USB: Select better matching USB drivers when availableBastien Nocera2-2/+42
Now that USB device drivers can reuse code from the generic USB device driver, we need to make sure that they get selected rather than the generic driver. Add an id_table and match vfunc to the usb_device_driver struct, which will get used to select a better matching driver at ->probe time. This is a similar mechanism to that used in the HID drivers, with the generic driver being selected unless there's a better matching one found in the registered drivers (see hid_generic_match() in drivers/hid/hid-generic.c). Signed-off-by: Bastien Nocera <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-12USB: Implement usb_device_match_id()Bastien Nocera2-0/+16
Match a usb_device with a table of IDs. Signed-off-by: Bastien Nocera <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-12USB: Make it possible to "subclass" usb_device_driverBastien Nocera1-5/+21
The kernel currenly has only 2 usb_device_drivers, one generic one, one that completely replaces the generic one to make USB devices usable over a network. Use the newly exported generic driver functions when a driver declares to want them run, in addition to its own code. This makes it possible to write drivers that extend the generic USB driver. Note that this patch is not enough for another driver to automatically get selected. Signed-off-by: Bastien Nocera <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-12USB: Export generic USB device driver functionsBastien Nocera2-8/+14
This will make it possible to implement device drivers which extend the generic driver without needing to reimplement it. Signed-off-by: Bastien Nocera <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-12USB: Fix novation SourceControl XL after suspendRichard Dodd1-0/+3
Currently, the SourceControl will stay in power-down mode after resuming from suspend. This patch resets the device after suspend to power it up. Signed-off-by: Richard Dodd <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.