summaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2018-06-20usb: musb: fix remote wakeup racing with suspendDaniel Glöckner3-13/+24
[ Upstream commit ebc3dd688cd988754a304147753b13e58de1b5a1 ] It has been observed that writing 0xF2 to the power register while it reads as 0xF4 results in the register having the value 0xF0, i.e. clearing RESUME and setting SUSPENDM in one go does not work. It might also violate the USB spec to transition directly from resume to suspend, especially when not taking T_DRSMDN into account. But this is what happens when a remote wakeup occurs between SetPortFeature USB_PORT_FEAT_SUSPEND on the root hub and musb_bus_suspend being called. This commit returns -EBUSY when musb_bus_suspend is called while remote wakeup is signalled and thus avoids to reset the RESUME bit. Ignoring this error when musb_port_suspend is called from musb_hub_control is ok. Signed-off-by: Daniel Glöckner <dg@emlix.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-20usb: typec: tps6598x: handle block reads separately with plain-I2C adaptersHeikki Krogerus1-8/+39
[ Upstream commit 1a2f474d328f292ee706414824ec4ca690cdf5ba ] If the I2C adapter that the PD controller is attached to does not support SMBus protocol, the driver needs to handle block reads separately. The first byte returned in block read protocol will show the total number of bytes. It needs to be stripped away. This is handled separately in the driver only because right now we have no way of requesting the used protocol with regmap-i2c. This is in practice a workaround for what is really a problem in regmap-i2c. The other option would have been to register custom regmap, or not use regmap at all, however, since the solution is very simple, I choose to use it in this case for convenience. It is easy to remove once we figure out how to handle this kind of cases in regmap-i2c. Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-20usb: typec: ucsi: fix tracepoint related build errorTobias Regnery1-1/+1
[ Upstream commit 2f860691c2d2e3af1404ffeb2d22dd5c3dbca811 ] There is the following build error with CONFIG_TYPEC_UCSI=m, CONFIG_FTRACE=y and CONFIG_TRACING=n: ERROR: "__tracepoint_ucsi_command" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_register_port" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_notify" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_reset_ppm" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_run_command" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_ack" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_connector_change" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! This compination is quite hard to create because CONFIG_TRACING gets selected only in rare cases without CONFIG_FTRACE. The build failure is caused by conditionally compiling trace.c depending on the wrong option CONFIG_FTRACE. Change this to depend on CONFIG_TRACING like other users of tracepoints do. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnectingYoshihiro Shimoda1-0/+7
commit bd6bce004d78b867ba0c6d3712f1c5b50398af9a upstream. This patch fixes an issue that reconnection is possible to fail because unexpected state handling happens by the irqs. To fix the issue, the driver disables the controller's irqs when disconnected. Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Cc: <stable@vger.kernel.org> # v4.5+ Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb: gadget: udc: renesas_usb3: should fail if devm_phy_get() returns errorYoshihiro Shimoda1-3/+5
commit 0259068f63f23a665ded28647f2f9cdb6b20dc72 upstream. This patch fixes an issue that this driver ignores errors other than the non-existence of the device, f.e. a memory allocation failure in devm_phy_get(). So, this patch replaces devm_phy_get() with devm_phy_optional_get(). Reported-by: Simon Horman <horms+renesas@verge.net.au> Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for generic phy") Cc: <stable@vger.kernel.org> # v4.15+ Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb: gadget: udc: renesas_usb3: should call devm_phy_get() before add udcYoshihiro Shimoda1-8/+8
commit 003bc1dee216b1fb8e02040a95672bea0f1fe797 upstream. This patch fixes an issue that this driver cannot call phy_init() if a gadget driver is alreadly loaded because usb_add_gadget_udc() might call renesas_usb3_start() via .udc_start. This patch also revises the typo (s/an optional/optional/). Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for generic phy") Cc: <stable@vger.kernel.org> # v4.15+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb: gadget: udc: renesas_usb3: should call pm_runtime_enable() before add udcYoshihiro Shimoda1-1/+1
commit d998844016b24a8d71b9aa5eae7e51d70f2de438 upstream. This patch fixes an issue that this driver causes panic if a gadget driver is already loaded because usb_add_gadget_udc() might call renesas_usb3_start() via .udc_start, and then pm_runtime_get_sync() in renesas_usb3_start() doesn't work correctly. Note that the usb3_to_dev() macro should not be called at this timing because the macro uses the gadget structure. Fixes: cf06df3fae28 ("usb: gadget: udc: renesas_usb3: move pm_runtime_{en,dis}able()") Cc: <stable@vger.kernel.org> # v4.15+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb: gadget: udc: renesas_usb3: should remove debugfsYoshihiro Shimoda1-1/+7
commit 1990cf7c21ea185cec98c6d45a82c04481261e35 upstream. This patch fixes an issue that this driver doesn't remove its debugfs. Fixes: 43ba968b00ea ("usb: gadget: udc: renesas_usb3: add debugfs to set the b-device mode") Cc: <stable@vger.kernel.org> # v4.14+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb: gadget: udc: renesas_usb3: fix double phy_put()Yoshihiro Shimoda1-2/+0
commit 8223b2f89ca63e203dcb54148e30d94979f17b0b upstream. This patch fixes an issue that this driver cause double phy_put() calling. This driver must not call phy_put() in the remove because the driver calls devm_phy_get() in the probe. Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for generic phy") Cc: <stable@vger.kernel.org> # v4.15+ Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb: gadget: function: printer: avoid wrong list handling in printer_write()Yoshihiro Shimoda1-3/+3
commit 4a014a7339f441b0851ce012f469c0fadac61c81 upstream. When printer_write() calls usb_ep_queue(), a udc driver (e.g. renesas_usbhs driver) may call usb_gadget_giveback_request() in the udc .queue ops immediately. Then, printer_write() calls list_add(&req->list, &dev->tx_reqs_active) wrongly. After that, if we do unbind the printer driver, WARN_ON() happens in printer_func_unbind() because the list entry is not removed. So, this patch moves list_add(&req->list, &dev->tx_reqs_active) calling before usb_ep_queue(). Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb: typec: wcove: Remove dependency on HW FSMHeikki Krogerus1-2/+28
commit 05826ff135ee083d28c006fbde6e810f17437166 upstream. The USB Type-C PHY in Intel WhiskeyCove PMIC has build-in USB Type-C state machine which we were relying on to configure the CC lines correctly. This patch removes that dependency and configures the CC line according to commands from the port manager (tcpm.c) in wcove_set_cc(). This fixes an issue where USB devices attached to the USB Type-C port do not get enumerated. When acting as source/host, the HW FSM sometimes fails to configure the PHY correctly. Fixes: 3c4fb9f16921 ("usb: typec: wcove: start using tcpm for USB PD support") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb: core: message: remove extra endianness conversion in usb_set_isoch_delayRuslan Bilovol1-1/+1
commit 48b73d0fa11aa8613d51f7be61d2fa7f0ab05fd3 upstream. No need to do extra endianness conversion in usb_set_isoch_delay because it is already done in usb_control_msg() Fixes: 886ee36e7205 ("usb: core: add support for USB_REQ_SET_ISOCH_DELAY") Cc: Dmytro Panchenko <dmytro.panchenko@globallogic.com> Cc: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: stable <stable@vger.kernel.org> # v4.16+ Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb-storage: Add compatibility quirk flags for G-Technologies G-DriveAlexander Kappner2-0/+18
commit ca7d9515d0e6825351ce106066cea1f60e40b1c8 upstream. The "G-Drive" (sold by G-Technology) external USB 3.0 drive hangs on write access under UAS and usb-storage: [ 136.079121] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 136.079144] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current] [ 136.079152] sd 15:0:0:0: [sdi] tag#0 Add. Sense: Invalid field in cdb [ 136.079176] sd 15:0:0:0: [sdi] tag#0 CDB: Write(16) 8a 08 00 00 00 00 00 00 00 00 00 00 00 08 00 00 [ 136.079180] print_req_error: critical target error, dev sdi, sector 0 [ 136.079183] Buffer I/O error on dev sdi, logical block 0, lost sync page write [ 136.173148] EXT4-fs (sdi): mounted filesystem with ordered data mode. Opts: (null) [ 140.583998] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 140.584010] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current] [ 140.584016] sd 15:0:0:0: [sdi] tag#0 Add. Sense: Invalid field in cdb [ 140.584022] sd 15:0:0:0: [sdi] tag#0 CDB: Write(16) 8a 08 00 00 00 00 e8 c4 00 18 00 00 00 08 00 00 [ 140.584025] print_req_error: critical target error, dev sdi, sector 3905159192 [ 140.584044] print_req_error: critical target error, dev sdi, sector 3905159192 [ 140.584052] Aborting journal on device sdi-8. The proposed patch adds compatibility quirks. Because the drive requires two quirks (one to work with UAS, and another to work with usb-storage), adding this under unusual_devs.h and not just unusual_uas.h so kernels compiled without UAS receive the quirk. With the patch, the drive works reliably on UAS and usb- storage. (tested on NEC Corporation uPD720200 USB 3.0 host controller). Signed-off-by: Alexander Kappner <agk@godking.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usb-storage: Add support for FL_ALWAYS_SYNC flag in the UAS driverAlexander Kappner1-0/+6
commit 8c4e97ddfe73a0958bb0abf7e6a3bc4cc3e04936 upstream. The ALWAYS_SYNC flag is currently honored by the usb-storage driver but not UAS and is required to work around devices that become unstable upon being queried for cache. This code is taken straight from: drivers/usb/storage/scsiglue.c:284 Signed-off-by: Alexander Kappner <agk@godking.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-16usbip: vhci_sysfs: fix potential Spectre v1Gustavo A. R. Silva1-8/+16
commit a0d6ec88090d7b1b008429c44532a388e29bb1bd upstream. pdev_nr and rhport can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_ss->vdev' drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_hs->vdev' Fix this by sanitizing pdev_nr and rhport before using them to index vhcis and vhci->vhci_hcd_ss->vdev respectively. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25xhci: Show what USB release number the xHC supports from protocol capablityMathias Nyman1-3/+11
[ Upstream commit 0ee78c101425aae681c631ba59c6ac7f44b1d83a ] xhci driver displays the supported xHC USB revision in a message during driver load: "Host supports USB 3.1 Enhanced SuperSpeed" Get the USB minor revision number from the xhci protocol capability. This will show the correct supported revisions for new USB 3.2 and later hosts Don't rely on the SBRN (serial bus revision number) register, it's often showing 0x30 (USB3.0) for hosts that support USB 3.1 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usb: gadget: composite: fix incorrect handling of OS desc requestsChris Dickens1-21/+19
[ Upstream commit 5d6ae4f0da8a64a185074dabb1b2f8c148efa741 ] When handling an OS descriptor request, one of the first operations is to zero out the request buffer using the wLength from the setup packet. There is no bounds checking, so a wLength > 4096 would clobber memory adjacent to the request buffer. Fix this by taking the min of wLength and the request buffer length prior to the memset. While at it, define the buffer length in a header file so that magic numbers don't appear throughout the code. When returning data to the host, the data length should be the min of the wLength and the valid data we have to return. Currently we are returning wLength, thus requests for a wLength greater than the amount of data in the OS descriptor buffer would return invalid (albeit zero'd) data following the valid descriptor data. Fix this by counting the number of bytes when constructing the data and using this when determining the length of the request. Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usb: gadget: udc: change comparison to bitshift when dealing with a maskWolfram Sang1-1/+1
[ Upstream commit ac87e560f7c0f91b62012e9a159c0681a373b922 ] Due to a typo, the mask was destroyed by a comparison instead of a bit shift. Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usbip: Correct maximum value of CONFIG_USBIP_VHCI_HC_PORTSBen Hutchings1-1/+1
[ Upstream commit 351a8d4837ae0d61744e64262c3a80ab92ff3e42 ] Now that usbip supports USB3, the maximum number of ports allowed on a hub is 15 (USB_SS_MAXPORTS), not 31 (USB_MAXCHILDREN). Reported-by: Gianluigi Tiesi <sherpya@netfarm.it> Reported-by: Borissh1983 <borissh1983@gmail.com> References: https://bugs.debian.org/878866 Fixes: 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed support") Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usb: gadget: ffs: Execute copy_to_user() with USER_DS setLars-Peter Clausen1-0/+4
[ Upstream commit 4058ebf33cb0be88ca516f968eda24ab7b6b93e4 ] When using a AIO read() operation on the function FS gadget driver a URB is submitted asynchronously and on URB completion the received data is copied to the userspace buffer associated with the read operation. This is done from a kernel worker thread invoking copy_to_user() (through copy_to_iter()). And while the user space process memory is made available to the kernel thread using use_mm(), some architecture require in addition to this that the operation runs with USER_DS set. Otherwise the userspace memory access will fail. For example on ARM64 with Privileged Access Never (PAN) and User Access Override (UAO) enabled the following crash occurs. Internal error: Accessing user space memory with fs=KERNEL_DS: 9600004f [#1] SMP Modules linked in: CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Workqueue: events ffs_user_copy_worker task: ffffffc87afc8080 task.stack: ffffffc87a00c000 PC is at __arch_copy_to_user+0x190/0x220 LR is at copy_to_iter+0x78/0x3c8 [...] [<ffffff800847b790>] __arch_copy_to_user+0x190/0x220 [<ffffff80086f25d8>] ffs_user_copy_worker+0x70/0x130 [<ffffff80080b8c64>] process_one_work+0x1dc/0x460 [<ffffff80080b8f38>] worker_thread+0x50/0x4b0 [<ffffff80080bf5a0>] kthread+0xd8/0xf0 [<ffffff8008083680>] ret_from_fork+0x10/0x50 Address this by placing a set_fs(USER_DS) before of the copy operation and revert it again once the copy operation has finished. This patch is analogous to commit d7ffde35e31a ("vhost: use USER_DS in vhost_worker thread") which addresses the same underlying issue. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUSLars-Peter Clausen1-1/+1
[ Upstream commit 946ef68ad4e45aa048a5fb41ce8823ed29da866a ] Some UDC drivers (like the DWC3) expect that the response to a setup() request is queued from within the setup function itself so that it is available as soon as setup() has completed. Upon receiving a setup request the function fs driver creates an event that is made available to userspace. And only once userspace has acknowledged that event the response to the setup request is queued. So it violates the requirement of those UDC drivers and random failures can be observed. This is basically a race condition and if userspace is able to read the event and queue the response fast enough all is good. But if it is not, for example because other processes are currently scheduled to run, the USB host that sent the setup request will observe an error. To avoid this the gadget framework provides the USB_GADGET_DELAYED_STATUS return code. If a setup() callback returns this value the UDC driver is aware that response is not yet available and can uses the appropriate methods to handle this case. Since in the case of function fs the response will never be available when the setup() function returns make sure that this status code is used. This fixed random occasional failures that were previously observed on a DWC3 based system under high system load. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usb: dwc2: host: Fix transaction errors in host modeMinas Harutyunyan1-1/+13
[ Upstream commit 92a8dd26464e1f21f1d869ec53717bd2c1200d63 ] Added missing GUSBCFG programming in host mode, which fixes transaction errors issue on HiKey and Altera Cyclone V boards. These field even if was programmed in device mode (in function dwc2_hsotg_core_init_disconnected()) will be resetting to POR values after core soft reset applied. So, each time when switching to host mode required to set this field to correct value. Acked-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Minas Harutyunyan <hminas@synopsys.com> Signed-off-by: Grigor Tovmasyan <tovmasya@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usb: dwc2: hcd: Fix host channel halt flowMinas Harutyunyan1-0/+18
[ Upstream commit a82c7abdf8fc3b09c4a0ed2eee6d43ecef2ccdb0 ] According databook in Buffer and External DMA mode non-split periodic channels can't be halted. Acked-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Minas Harutyunyan <hminas@synopsys.com> Signed-off-by: Grigor Tovmasyan <tovmasya@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usb: dwc2: Fix interval type issueGrigor Tovmasyan1-1/+1
[ Upstream commit 12814a3f8f9b247531d7863170cc82b3fe4218fd ] The maximum value that unsigned char can hold is 255, meanwhile the maximum value of interval is 2^(bIntervalMax-1)=2^15. Signed-off-by: Grigor Tovmasyan <tovmasya@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25xhci: zero usb device slot_id member when disabling and freeing a xhci slotMathias Nyman1-0/+2
[ Upstream commit a400efe455f7b61ac9a801ac8d0d01f8c8d82dd5 ] set udev->slot_id to zero when disabling and freeing the xhci slot. Prevents usb core from calling xhci with a stale slot id. xHC controller may be reset during resume to recover from some error. All slots are unusable as they are disabled and freed. xhci driver starts slot enumeration again from 1 in the order they are enabled. In the worst case a stale udev->slot_id for one device matches a newly enabled slot_id for a different device, causing us to perform a action on the wrong device. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usb: dwc3: Makefile: fix link error on randconfigFelipe Balbi1-1/+1
[ Upstream commit de948a74ad6f0eefddf36d765b8f2dd6df82caa0 ] If building a kernel without FTRACE but with TRACING, dwc3.ko fails to link due to missing trace events. Fix this by using the correct Kconfig symbol on Makefile. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fieldsThinh Nguyen1-0/+2
[ Upstream commit 0cab8d26d6e5e053b2bed3356992aaa71dc93628 ] Update two GTXFIFOSIZ bit fields for the DWC_usb31 controller. TXFDEP is a 15-bit value instead of 16-bit value, and bit 15 is TXFRAMNUM. The GTXFIFOSIZ register for DWC_usb31 is as follows: +-------+-----------+----------------------------------+ | BITS | Name | Description | +=======+===========+==================================+ | 31:16 | TXFSTADDR | Transmit FIFOn RAM Start Address | | 15 | TXFRAMNUM | Asynchronous/Periodic TXFIFO | | 14:0 | TXFDEP | TXFIFO Depth | +-------+-----------+----------------------------------+ Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-25usb: dwc3: Add SoftReset PHY synchonization delayThinh Nguyen1-1/+12
[ Upstream commit fab3833338779e1e668bd58d1f76d601657304b8 ] >From DWC_usb31 programming guide section 1.3.2, once DWC3_DCTL_CSFTRST bit is cleared, we must wait at least 50ms before accessing the PHY domain (synchronization delay). Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-22usbip: usbip_host: fix bad unlock balance during stub_probe()Shuah Khan (Samsung OSG)1-1/+2
commit c171654caa875919be3c533d3518da8be5be966e upstream. stub_probe() calls put_busid_priv() in an error path when device isn't found in the busid_table. Fix it by making put_busid_priv() safe to be called with null struct bus_id_priv pointer. This problem happens when "usbip bind" is run without loading usbip_host driver and then running modprobe. The first failed bind attempt unbinds the device from the original driver and when usbip_host is modprobed, stub_probe() runs and doesn't find the device in its busid table and calls put_busid_priv(0 with null bus_id_priv pointer. usbip-host 3-10.2: 3-10.2 is not in match_busid table... skip! [ 367.359679] ===================================== [ 367.359681] WARNING: bad unlock balance detected! [ 367.359683] 4.17.0-rc4+ #5 Not tainted [ 367.359685] ------------------------------------- [ 367.359688] modprobe/2768 is trying to release lock ( [ 367.359689] ================================================================== [ 367.359696] BUG: KASAN: null-ptr-deref in print_unlock_imbalance_bug+0x99/0x110 [ 367.359699] Read of size 8 at addr 0000000000000058 by task modprobe/2768 [ 367.359705] CPU: 4 PID: 2768 Comm: modprobe Not tainted 4.17.0-rc4+ #5 Fixes: 22076557b07c ("usbip: usbip_host: fix NULL-ptr deref and use-after-free errors") in usb-linus Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-22usbip: usbip_host: fix NULL-ptr deref and use-after-free errorsShuah Khan (Samsung OSG)3-15/+60
commit 22076557b07c12086eeb16b8ce2b0b735f7a27e7 upstream. usbip_host updates device status without holding lock from stub probe, disconnect and rebind code paths. When multiple requests to import a device are received, these unprotected code paths step all over each other and drive fails with NULL-ptr deref and use-after-free errors. The driver uses a table lock to protect the busid array for adding and deleting busids to the table. However, the probe, disconnect and rebind paths get the busid table entry and update the status without holding the busid table lock. Add a new finer grain lock to protect the busid entry. This new lock will be held to search and update the busid entry fields from get_busid_idx(), add_match_busid() and del_match_busid(). match_busid_show() does the same to access the busid entry fields. get_busid_priv() changed to return the pointer to the busid entry holding the busid lock. stub_probe(), stub_disconnect() and stub_device_rebind() call put_busid_priv() to release the busid lock before returning. This changes fixes the unprotected code paths eliminating the race conditions in updating the busid entries. Reported-by: Jakub Jirasek Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-22usbip: usbip_host: run rebind from exit when module is removedShuah Khan (Samsung OSG)2-14/+52
commit 7510df3f29d44685bab7b1918b61a8ccd57126a9 upstream. After removing usbip_host module, devices it releases are left without a driver. For example, when a keyboard or a mass storage device are bound to usbip_host when it is removed, these devices are no longer bound to any driver. Fix it to run device_attach() from the module exit routine to restore the devices to their original drivers. This includes cleanup changes and moving device_attach() code to a common routine to be called from rebind_store() and usbip_host_exit(). Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-22usbip: usbip_host: delete device from busid_table after rebindShuah Khan (Samsung OSG)1-0/+6
commit 1e180f167d4e413afccbbb4a421b48b2de832549 upstream. Device is left in the busid_table after unbind and rebind. Rebind initiates usb bus scan and the original driver claims the device. After rescan the device should be deleted from the busid_table as it no longer belongs to usbip_host. Fix it to delete the device after device_attach() succeeds. Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-22usbip: usbip_host: refine probe and disconnect debug msgs to be usefulShuah Khan1-2/+2
commit 28b68acc4a88dcf91fd1dcf2577371dc9bf574cc upstream. Refine probe and disconnect debug msgs to be useful and say what is in progress. Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-22xhci: Fix USB3 NULL pointer dereference at logical disconnect.Mathias Nyman1-1/+1
commit 2278446e2b7cd33ad894b32e7eb63afc7db6c86e upstream. Hub driver will try to disable a USB3 device twice at logical disconnect, racing with xhci_free_dev() callback from the first port disable. This can be triggered with "udisksctl power-off --block-device <disk>" or by writing "1" to the "remove" sysfs file for a USB3 device in 4.17-rc4. USB3 devices don't have a similar disabled link state as USB2 devices, and use a U3 suspended link state instead. In this state the port is still enabled and connected. hub_port_connect() first disconnects the device, then later it notices that device is still enabled (due to U3 states) it will try to disable the port again (set to U3). The xhci_free_dev() called during device disable is async, so checking for existing xhci->devs[i] when setting link state to U3 the second time was successful, even if device was being freed. The regression was caused by, and whole thing revealed by, Commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device") which sets xhci->devs[i]->udev to NULL before xhci_virt_dev() returned. and causes a NULL pointer dereference the second time we try to set U3. Fix this by checking xhci->devs[i]->udev exists before setting link state. The original patch went to stable so this fix needs to be applied there as well. Fixes: 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device") Cc: <stable@vger.kernel.org> Reported-by: Jordan Glover <Golden_Miller83@protonmail.ch> Tested-by: Jordan Glover <Golden_Miller83@protonmail.ch> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-09usb: musb: trace: fix NULL pointer dereference in musb_g_tx()Bin Liu1-1/+2
commit 9aea9b6cc78d2b99b23d84fb2e0bc6e464c6569e upstream. The usb_request pointer could be NULL in musb_g_tx(), where the tracepoint call would trigger the NULL pointer dereference failure when parsing the members of the usb_request pointer. Move the tracepoint call to where the usb_request pointer is already checked to solve the issue. Fixes: fc78003e5345 ("usb: musb: gadget: add usb-request tracepoints") Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-09usb: musb: host: fix potential NULL pointer dereferenceBin Liu1-1/+3
commit 2b63f1329df2cd814c1f8353fae4853ace6521d1 upstream. musb_start_urb() doesn't check the pass-in parameter if it is NULL. But in musb_bulk_nak_timeout() the parameter passed to musb_start_urb() is returned from first_qh(), which could be NULL. So wrap the musb_start_urb() call here with a if condition check to avoid the potential NULL pointer dereference. Fixes: f283862f3b5c ("usb: musb: NAK timeout scheme on bulk TX endpoint") Cc: stable@vger.kernel.org # v3.7+ Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-09USB: serial: option: adding support for ublox R410MSZ Lin (林上智)1-0/+5
commit 4205cb01f6e9ef2ae6daa7be4e8ac1edeb4c9d64 upstream. This patch adds support for ublox R410M PID 0x90b2 USB modem to option driver, this module supports LTE Cat M1 / NB1. Interface layout: 0: QCDM/DIAG 1: ADB 2: AT 3: RMNET Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-09USB: serial: option: reimplement interface maskingJohan Hovold1-294/+152
commit c3a65808f04a8426481b63a4fbd9392f009f6330 upstream. Reimplement interface masking using device flags stored directly in the device-id table. This will make it easier to add and maintain device-id entries by using a more compact and readable notation compared to the current implementation (which manages pairs of masks in separate blacklist structs). Two convenience macros are used to flag an interface as either reserved or as not supporting modem-control requests: { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM), .driver_info = NCTRL(0) | RSVD(3) }, For now, we limit the highest maskable interface number to seven, which allows for (up to 16) additional device flags to be added later should need arise. Note that this will likely need to be backported to stable in order to make future device-id backports more manageable. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-09USB: Accept bulk endpoints with 1024-byte maxpacketAlan Stern1-1/+3
commit fb5ee84ea72c5f1b6cabdd1c9d6e8648995ca7c6 upstream. Some non-compliant high-speed USB devices have bulk endpoints with a 1024-byte maxpacket size. Although such endpoints don't work with xHCI host controllers, they do work with EHCI controllers. We used to accept these invalid sizes (with a warning), but we no longer do because of an unintentional change introduced by commit aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors"). This patch restores the old behavior, so that people with these peculiar devices can use them without patching their kernels by hand. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Suggested-by: Elvinas <elvinas@veikia.lt> Fixes: aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors") CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-09usb: dwc3: gadget: Fix list_del corruption in dwc3_ep_dequeueMayank Rana1-1/+1
commit 96bd39df29c29d348d65311e5954c0b7d3a2a790 upstream. dwc3_ep_dequeue() waits for completion of End Transfer command using wait_event_lock_irq(), which will release the dwc3->lock while waiting and reacquire after completion. This allows a potential race condition with ep_disable() which also removes all requests from started_list and pending_list. The check for NULL r->trb should catch this but currently it exits to the wrong 'out1' label which calls dwc3_gadget_giveback(). Since its list entry was already removed, if CONFIG_DEBUG_LIST is enabled a 'list_del corruption' bug is thrown since its next/prev pointers are already LIST_POISON1/2. If r->trb is NULL it should simply exit to 'out0'. Fixes: cf3113d893d4 ("usb: dwc3: gadget: properly increment dequeue pointer on ep_dequeue") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Mayank Rana <mrana@codeaurora.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-09USB: serial: visor: handle potential invalid device configurationGreg Kroah-Hartman1-34/+35
commit 4842ed5bfcb9daf6660537d70503c18d38dbdbb8 upstream. If we get an invalid device configuration from a palm 3 type device, we might incorrectly parse things, and we have the potential to crash in "interesting" ways. Fix this up by verifying the size of the configuration passed to us by the device, and only if it is correct, will we handle it. Note that this also fixes an information leak of slab data. Reported-by: Andrey Konovalov <andreyknvl@google.com> Reviewed-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [ johan: add comment about the info leak ] Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-09xhci: Fix use-after-free in xhci_free_virt_deviceMathias Nyman1-0/+1
commit 44a182b9d17765514fa2b1cc911e4e65134eef93 upstream. KASAN found a use-after-free in xhci_free_virt_device+0x33b/0x38e where xhci_free_virt_device() sets slot id to 0 if udev exists: if (dev->udev && dev->udev->slot_id) dev->udev->slot_id = 0; dev->udev will be true even if udev is freed because dev->udev is not set to NULL. set dev->udev pointer to NULL in xhci_free_dev() The original patch went to stable so this fix needs to be applied there as well. Fixes: a400efe455f7 ("xhci: zero usb device slot_id member when disabling and freeing a xhci slot") Cc: <stable@vger.kernel.org> Reported-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-01USB: Increment wakeup count on remote wakeup.Ravi Chandra Sadineni2-1/+10
commit 83a62c51ba7b3c0bf45150c4eac7aefc6c785e94 upstream. On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a wake capable device, if wake enabled, drives resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7). The upstream facing port then sets C_PORT_SUSPEND bit and reports a port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port has resumed before driving the resume signal from the host and C_PORT_SUSPEND is set, then the device attached to the given port might be the reason for the last system wakeup. Increment the wakeup count for the same. On USB 3.0 devices, a function may signal that it wants to exit from device suspend by sending a Function Wake Device Notification to the host (USB3.0 spec section 8.5.6.4) Thus on receiving the Function Wake, increment the wakeup count. Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-01usb: core: Add quirk for HP v222w 16GB MiniKamil Lulko1-0/+3
commit 3180dabe08e3653bf0a838553905d88f3773f29c upstream. Add DELAY_INIT quirk to fix the following problem with HP v222w 16GB Mini: usb 1-3: unable to read config index 0 descriptor/start: -110 usb 1-3: can't read configurations, error -110 usb 1-3: can't set config #1, error -110 Signed-off-by: Kamil Lulko <kamilx.lulko@intel.com> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-01usb: typec: ucsi: Increase command completion timeout valueHeikki Krogerus1-1/+1
commit b1b59e16075f5e5da2943ce8de724ab96bc3c6c2 upstream. On some boards, under heavy load, the EC firmware is unable to complete commands even in one second. Increasing the command completion timeout value to five seconds. Reported-by: Quanxian Wang <quanxian.wang@intel.com> Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: <stable@vger.kernel.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-01USB: serial: cp210x: add ID for NI USB serial consoleKyle Roeschley1-0/+1
commit 1e23aace21515a8f7615a1de016c0ea8d4e0cc6e upstream. Added the USB VID and PID for the USB serial console on some National Instruments devices. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-01USB: serial: ftdi_sio: use jtag quirk for Arrow USB BlasterVasyl Vavrychuk1-1/+2
commit 470b5d6f0cf4674be2d1ec94e54283a1770b6a1a upstream. Arrow USB Blaster integrated on MAX1000 board uses the same vendor ID (0x0403) and product ID (0x6010) as the "original" FTDI device. This patch avoids picking up by ftdi_sio of the first interface of this USB device. After that this device can be used by Arrow user-space JTAG driver. Signed-off-by: Vasyl Vavrychuk <vvavrychuk@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-01USB: serial: simple: add libtransistor consoleCollin May2-0/+8
commit fe710508b6ba9d28730f3021fed70e7043433b2e upstream. Add simple driver for libtransistor USB console. This device is implemented in software: https://github.com/reswitched/libtransistor/blob/development/lib/usb_serial.c Signed-off-by: Collin May <collin@collinswebsite.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-01xhci: Fix USB ports for Dell Inspiron 5775Kai-Heng Feng1-1/+4
commit 621faf4f6a181b6e012c1d1865213f36f4159b7f upstream. The Dell Inspiron 5775 is a Raven Ridge. The Enable Slot command timed out when a USB device gets plugged: [ 212.156326] xhci_hcd 0000:03:00.3: Error while assigning device slot ID [ 212.156340] xhci_hcd 0000:03:00.3: Max number of devices this xHCI host supports is 64. [ 212.156348] usb usb2-port3: couldn't allocate usb_device AMD suggests that a delay before xHC suspends can fix the issue. I can confirm it fixes the issue, so use the suspend delay quirk for Raven Ridge's xHC. Cc: stable@vger.kernel.org Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-01xhci: Fix Kernel oops in xhci dbgttyZhengjun Xing1-3/+5
commit 7fc65d4c2ba9e5006c629669146c6876b65aa233 upstream. tty_unregister_driver may be called more than 1 time in some hotplug cases,it will cause the kernel oops. This patch checked dbc_tty_driver to make sure it is unregistered only 1 time. [ 175.741404] BUG: unable to handle kernel NULL pointer dereference at 0000000000000034 [ 175.742309] IP: tty_unregister_driver+0x9/0x70 [ 175.743148] PGD 0 P4D 0 [ 175.743981] Oops: 0000 [#1] SMP PTI [ 175.753904] RIP: 0010:tty_unregister_driver+0x9/0x70 [ 175.754817] RSP: 0018:ffffa8ff831d3bb0 EFLAGS: 00010246 [ 175.755753] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 175.756685] RDX: ffff92089c616000 RSI: ffffe64fe1b26080 RDI: 0000000000000000 [ 175.757608] RBP: ffff92086c988230 R08: 000000006c982701 R09: 00000001801e0016 [ 175.758533] R10: ffffa8ff831d3b48 R11: ffff92086c982100 R12: ffff92086c98827c [ 175.759462] R13: ffff92086c988398 R14: 0000000000000060 R15: ffff92089c5e9b40 [ 175.760401] FS: 0000000000000000(0000) GS:ffff9208a0100000(0000) knlGS:0000000000000000 [ 175.761334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 175.762270] CR2: 0000000000000034 CR3: 000000011800a003 CR4: 00000000003606e0 [ 175.763225] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 175.764164] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 175.765091] Call Trace: [ 175.766014] xhci_dbc_tty_unregister_driver+0x11/0x30 [ 175.766960] xhci_dbc_exit+0x2a/0x40 [ 175.767889] xhci_stop+0x57/0x1c0 [ 175.768824] usb_remove_hcd+0x100/0x250 [ 175.769708] usb_hcd_pci_remove+0x68/0x130 [ 175.770574] pci_device_remove+0x3b/0xc0 [ 175.771435] device_release_driver_internal+0x157/0x230 [ 175.772343] pci_stop_bus_device+0x74/0xa0 [ 175.773205] pci_stop_bus_device+0x2b/0xa0 [ 175.774061] pci_stop_bus_device+0x2b/0xa0 [ 175.774907] pci_stop_bus_device+0x2b/0xa0 [ 175.775741] pci_stop_bus_device+0x2b/0xa0 [ 175.776618] pci_stop_bus_device+0x2b/0xa0 [ 175.777452] pci_stop_bus_device+0x2b/0xa0 [ 175.778273] pci_stop_bus_device+0x2b/0xa0 [ 175.779092] pci_stop_bus_device+0x2b/0xa0 [ 175.779908] pci_stop_bus_device+0x2b/0xa0 [ 175.780750] pci_stop_bus_device+0x2b/0xa0 [ 175.781543] pci_stop_and_remove_bus_device+0xe/0x20 [ 175.782338] pciehp_unconfigure_device+0xb8/0x160 [ 175.783128] pciehp_disable_slot+0x4f/0xd0 [ 175.783920] pciehp_power_thread+0x82/0xa0 [ 175.784766] process_one_work+0x147/0x3c0 [ 175.785564] worker_thread+0x4a/0x440 [ 175.786376] kthread+0xf8/0x130 [ 175.787174] ? rescuer_thread+0x360/0x360 [ 175.787964] ? kthread_associate_blkcg+0x90/0x90 [ 175.788798] ret_from_fork+0x35/0x40 Cc: <stable@vger.kernel.org> # 4.16 Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Zhengjun Xing <zhengjun.xing@linux.intel.com> Tested-by: Christian Kellner <christian@kellner.me> Reviewed-by: Christian Kellner <christian@kellner.me> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>