- 18 Nov, 2019 6 commits
-
-
Peter Chen authored
Not every platform needs this regulator. Signed-off-by:Peter Chen <peter.chen@nxp.com>
-
Li Jun authored
As usbmisc_data is optional, so add the check before access its member, this fix below static checker warning: drivers/usb/chipidea/ci_hdrc_imx.c:438 ci_hdrc_imx_probe() warn: 'data->usbmisc_data' can also be NULL which is introduced by Patch 15b80f7c3a7f: "usb: chipidea: imx: enable vbus and id wakeup only for OTG events" Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Li Jun <jun.li@nxp.com> Signed-off-by:
-
Peter Chen authored
Vbus regualtor is an optional regulator, for platforms, which doesn't have this regulator, it will get a dummy regulator and show warning message. Signed-off-by: -
Li Jun authored
If ID or VBUS is from external block, don't enable its wakeup because it isn't used at all. Signed-off-by:
-
Jun Li authored
We hit the problem with below sequence: - ci_udc_vbus_session() update vbus_active flag and ci->driver is valid, - before calling the ci_hdrc_gadget_connect(), usb_gadget_udc_stop() is called by application remove gadget driver, - ci_udc_vbus_session() will contine do ci_hdrc_gadget_connect() as gadget_ready is 1, so udc interrupt is enabled, but ci->driver is NULL. - USB connection irq generated but ci->driver is NULL. As udc irq only should be enabled when gadget driver is binded, so add spinlock to protect the usb irq enable for vbus session handling. Signed-off-by:
-
Peter Chen authored
This API is used enable device function, it is called at below situations: - VBUS is connected during boots up - Hot plug occurs during runtime Signed-off-by:
-
- 16 Nov, 2019 5 commits
-
-
Hans de Goede authored
All configuration can and should be done through fwnodes instead of through the tcpc_config struct and there are no existing users left of struct tcpc_config, so lets remove it. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20191114111840.40876-1-hdegoede@redhat.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mika Westerberg authored
Intel Ice Lake has two xHCI controllers one on PCH and the other as part of the CPU itself. The latter is also part of the so called Type C Subsystem (TCSS) sharing ACPI power resources with the PCIe root ports and the Thunderbolt controllers. In order to put the whole TCSS block into D3cold the xHCI needs to be runtime suspended as well when idle. For this reason allow runtime PM as default for Ice Lake TCSS xHCI controller. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1573836603-10871-5-git-send-email-mathias.nyman@linux.intel.comSigned-off-by:
-
Suwan Kim authored
Patch "USB: HCD: support giveback of URB in tasklet context"[1] introduced giveback of urb in tasklet context. [1] This patch was applied to ehci but not xhci. [2] This patch significantly reduces the hard irq time of xhci. Especially for uvc driver, the hard irq including the uvc completion function runs quite long but applying this patch reduces the hard irq time of xhci. I have tested four SS devices to check if performance degradation occurs when urb completion functions run in the tasklet context. As a result of the test, all devices works well and shows very similar performance with the upstream kernel. Moreover, usb ethernet adapter show better performance than the upstream kernel about 5% for RX and 2% for TX. Four SS devices is as follows. SS devices for test 1. WD My Passport 2TB (external hard drive) 2. Sandisk Ultra Flair USB 3.0 32GB 3. Logitech Brio webcam 4. Iptime 1gigabit ethernet adapter (Mediatek RTL8153) Test description 1. Mass storage (hard drive) performance test - run below command 10 times and compute the average performance dd if=/dev/sdN iflag=direct of=/dev/null bs=1G count=1 2. Mass storage (flash memory) performance test - run below command 10 times and compute the average performance dd if=/dev/sdN iflag=direct of=/dev/null bs=1G count=1 3. Webcam streaming performance test - run simple capture program and get the average frame rate per second - capture 1500 frames - program link https://github.com/asfaca/Webcam-performance-analyzing-tool - video resolution : 4096 X 2160 (4K) at 30 or 24 fps - device (Logitech Brio) spec url for the highest resolution and fps https://support.logitech.com/en_gb/product/brio-stream/specs 4. USB Ethernet adapter performance test - directly connect two linux machines with ethernet cable - run pktgen of linux kernel and send 1500 bytes packets - run vnstat to measure the network bandwidth for 180 seconds Test machine - CPU : Intel i5-7600 @ 3.5GHz Test results 1. Mass storage (hard drive) performance test WD My Passport 2TB (external hard drive) -------------------------------------------------------------------- xhci without tasklet | xhci with tasklet -------------------------------------------------------------------- 103.667MB/s | 103.692MB/s -------------------------------------------------------------------- 2. Mass storage (flash memory) performance test Sandisk Ultra Flair USB 3.0 32GB -------------------------------------------------------------------- xhci without tasklet | xhci with tasklet -------------------------------------------------------------------- 129.727MB/s | 130.2MB/s -------------------------------------------------------------------- 3. Webcam streaming performance test Logitech Brio webcam -------------------------------------------------------------------- xhci without tasklet | xhci with tasklet -------------------------------------------------------------------- 26.4451 fps | 26.3949 fps -------------------------------------------------------------------- 4. USB Ethernet adapter performance test Iptime 1gigabit ethernet adapter (Mediatek RTL8153) -------------------------------------------------------------------- xhci without tasklet | xhci with tasklet -------------------------------------------------------------------- RX 933.86 Mbit/s | 983.86 Mbit/s -------------------------------------------------------------------- TX 830.18 Mbit/s | 882.75 Mbit/s -------------------------------------------------------------------- [1], https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=94dfd7edfd5c9b605caf7b562de7a813d216e011 [2], https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=428aac8a81058e2303677a8fbf26670229e51d3aSigned-off-by:Suwan Kim <suwan.kim027@gmail.com> Signed-off-by:
-
Mathias Nyman authored
Trace when a register in the doorbell array is written, both for host controller command doorbell and device doorbells, including for which endpoint and stream Signed-off-by:
-
Peter Chen authored
On some situations, the software handles TRB events slower than adding TRBs, then xhci_handle_event can't return zero long time, the xHC will consider the event ring is full, and trigger "Event Ring Full" error, but in fact, the software has already finished lots of events, just no chance to update ERDP (event ring dequeue pointer). In this commit, we force update ERDP if half of TRBS_PER_SEGMENT events have handled to avoid "Event Ring Full" error. Signed-off-by:
-
- 15 Nov, 2019 1 commit
-
-
Greg Kroah-Hartman authored
Merge tag 'usb-serial-5.5-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB-serial updates for 5.5-rc1 Here are the USB-serial updates for 5.5-rc1, including: - support for a new class of pl2303 devices - improved divisor calculations for ch341 - fixes for a remote-wakeup bug in the moschip drivers - improved device-type handling in mos7840 - various cleanups of mos7840 Included are also some new device ids. All have been in linux-next with no reported issues. Signed-off-by:
Johan Hovold <johan@kernel.org> * tag 'usb-serial-5.5-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: ftdi_sio: add device IDs for U-Blox C099-F9P USB: serial: option: add support for Foxconn T77W968 LTE modules USB: serial: mos7840: drop port open flag USB: serial: mos7840: drop read-urb check USB: serial: mos7840: drop port driver data accessors USB: serial: mos7840: drop serial struct accessor USB: serial: mos7840: drop paranoid serial checks USB: serial: mos7840: drop paranoid port checks USB: serial: mos7840: drop redundant urb context check USB: serial: mos7840: rip out broken interrupt handling USB: serial: mos7840: fix probe error handling USB: serial: mos7840: document MCS7810 detection hack USB: serial: mos7840: clean up device-type handling USB: serial: mos7840: fix remote wakeup USB: serial: mos7720: fix remote wakeup USB: serial: option: add support for DW5821e with eSIM support USB: serial: mos7840: add USB ID to support Moxa UPort 2210 USB: serial: ch341: reimplement line-speed handling USB: serial: pl2303: add support for PL2303HXN
-
- 14 Nov, 2019 12 commits
-
-
Fabio D'Urso authored
This device presents itself as a USB hub with three attached devices: - An ACM serial port connected to the GPS module (not affected by this commit) - An FTDI serial port connected to the GPS module (1546:0502) - Another FTDI serial port connected to the ODIN-W2 radio module (1546:0503) This commit registers U-Blox's VID and the PIDs of the second and third devices. Datasheet: https://www.u-blox.com/sites/default/files/C099-F9P-AppBoard-Mbed-OS3-FW_UserGuide_%28UBX-18063024%29.pdfSigned-off-by:
Fabio D'Urso <fabiodurso@hotmail.it> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Chunfeng Yun authored
Now the USB gadget subsystem can use the USB debugfs root directory, so move it's directory from the root of the debugfs filesystem into the root of usb Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1573541519-28488-13-git-send-email-chunfeng.yun@mediatek.comSigned-off-by:
-
Chunfeng Yun authored
Now the USB gadget subsystem can use the USB debugfs root directory, so move it's directory from the root of the debugfs filesystem into the root of usb Signed-off-by:
-
Chunfeng Yun authored
Now the USB gadget subsystem can use the USB debugfs root directory, so move it's directory from the root of the debugfs filesystem into the root of usb Signed-off-by:
-
Chunfeng Yun authored
Now the USB gadget subsystem can use the USB debugfs root directory, so move it's directory from the root of the debugfs filesystem into the root of usb Signed-off-by:
-
Chunfeng Yun authored
Now the USB gadget subsystem can use the USB debugfs root directory, so move dwc2's directory from the root of the debugfs filesystem into the root of usb Signed-off-by:
-
Chunfeng Yun authored
Now the USB gadget subsystem can use the USB debugfs root directory, so move dsps's directory from the root of the debugfs filesystem into the root of usb Signed-off-by:
-
Chunfeng Yun authored
No need check the return value of debugfs_create_dir() Signed-off-by:
-
Chunfeng Yun authored
Now the USB gadget subsystem can use the USB debugfs root directory, so move dwc3's directory from the root of the debugfs filesystem into the root of usb Signed-off-by:
-
Chunfeng Yun authored
Move it's directory from the root of the debugfs filesystem into the root of usb Signed-off-by:
-
Chunfeng Yun authored
Move it's directory from the root of the debugfs filesystem into the root of usb Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel_reason() is: #define dma_request_slave_channel_reason(dev, name) \ dma_request_chan(dev, name) Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20191113094838.2141-1-peter.ujfalusi@ti.comSigned-off-by:
-
- 13 Nov, 2019 2 commits
-
-
Aleksander Morgado authored
These are the Foxconn-branded variants of the Dell DW5821e modules, same USB layout as those. The device exposes AT, NMEA and DIAG ports in both USB configurations. P: Vendor=0489 ProdID=e0b4 Rev=03.18 S: Manufacturer=FII S: Product=T77W968 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option P: Vendor=0489 ProdID=e0b4 Rev=03.18 S: Manufacturer=FII S: Product=T77W968 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Signed-off-by:
Aleksander Morgado <aleksander@aleksander.es> [ johan: drop id defines ] Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Suwan Kim authored
Smatch reported that nents is not initialized and used in stub_recv_cmd_submit(). nents is currently initialized by sgl_alloc() and used to allocate multiple URBs when host controller doesn't support scatter-gather DMA. The use of uninitialized nents means that buf_len is zero and use_sg is true. But buffer length should not be zero when an URB uses scatter-gather DMA. To prevent this situation, add the conditional that checks buf_len and use_sg. And move the use of nents right after the sgl_alloc() to avoid the use of uninitialized nents. If the error occurs, it adds SDEV_EVENT_ERROR_MALLOC and stub_priv will be released by stub event handler and connection will be shut down. Fixes: ea44d190 ("usbip: Implement SG support to vhci-hcd and stub driver") Reported-by:
kbuild test robot <lkp@intel.com> Reported-by:
Shuah Khan <skhan@linuxfoundation.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191111141035.27788-1-suwan.kim027@gmail.comSigned-off-by:
-
- 12 Nov, 2019 14 commits
-
-
Oliver Neukum authored
USBIP uses lib/scatterlist.h Hence it needs to set CONFIG_SGL_ALLOC Signed-off-by:
Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Acked-by:
-
Johan Hovold authored
Drop the redundant port open flag and corresponding checks. USB serial core will not call any of these driver callbacks for a closed port, and the write URBs are stopped at close(). Reviewed-by:
-
Johan Hovold authored
Drop read-urb check which is always false from completion the callback. The driver read-urb pointer is set at every open and is never cleared. Reviewed-by:
-
Johan Hovold authored
Drop the custom port driver data accessors and paranoid sanity checks. The driver data is not cleared until the driver is unbound. Reviewed-by:
-
Johan Hovold authored
Drop the helper used to retrieve the serial struct pointer from the port structure. Note that this helper was only used when the serial structure was actually not needed. Reviewed-by:
-
Johan Hovold authored
Drop the likewise paranoid serial structure sanity checks. USB serial core sets the serial pointer in the port structures at initialisation and it is never cleared, and similar for the serial structure type. Reviewed-by:
-
Johan Hovold authored
Drop the paranoid port structure sanity checks which are confusing at best. The driver data port pointer is set at port probe and never cleared, while USB serial core sets the tty driver data at install and won't call any driver functions with a NULL port pointer. Reviewed-by:
-
Johan Hovold authored
The bulk-in URB context is set to the driver-data struct at open and is never cleared so drop the redundant check in the completion callback. Reviewed-by:
-
Johan Hovold authored
The interrupt handling is completely broken and has in fact never been been enabled due to an inverted test for an interrupt endpoint in open() that prevented the interrupt URB from being submitted. Other highlights include missing interrupt URB resubmission (had it ever been submitted), missing locking when managing the open-port count, and NULL-pointer dereferences that could have been triggered by a malicious device. Rip out this broken crap which is beyond repair instead of pretending we support this feature. Reviewed-by:
-
Johan Hovold authored
The driver would return success and leave the port structures half-initialised if any of the register accesses during probe fails. This would specifically leave the port control urb unallocated, something which could trigger a NULL pointer dereference on interrupt events. Fortunately the interrupt implementation is completely broken and has never even been enabled... Note that the zero-length-enable register write used to set the zle-flag for all ports is moved to attach. Reviewed-by:
-
Johan Hovold authored
Document the MCS7810 detection hack which relies on having the GPO and GPI pins connected as recommended by ASIX. Note that GPO (pin 42) is really RTS of the third port which will be toggled for the corresponding physical port on two- and four-port devices. Reviewed-by:
-
Johan Hovold authored
The current device-type detection is fragile and can't really be relied upon. Instead of sprinkling device-id conditionals throughout the driver, let's use the device-id table to encode the number of ports and whether the device has a driver-controlled activity LED (MCS7810). Reviewed-by:
-
Johan Hovold authored
The driver was setting the device remote-wakeup feature during probe in violation of the USB specification (which says it should only be set just prior to suspending the device). This could potentially waste power during suspend as well as lead to spurious wakeups. Note that USB core would clear the remote-wakeup feature at first resume. Fixes: 3f542974 ("USB: Moschip 7840 USB-Serial Driver") Cc: stable <stable@vger.kernel.org> # 2.6.19 Reviewed-by:
-
Johan Hovold authored
The driver was setting the device remote-wakeup feature during probe in violation of the USB specification (which says it should only be set just prior to suspending the device). This could potentially waste power during suspend as well as lead to spurious wakeups. Note that USB core would clear the remote-wakeup feature at first resume. Fixes: 0f64478c ("USB: add USB serial mos7720 driver") Cc: stable <stable@vger.kernel.org> # 2.6.19 Reviewed-by:
-
