- 03 Sep, 2019 39 commits
-
-
Alan Stern authored
The syzbot fuzzer found a lockdep violation in the rio500 driver: ====================================================== WARNING: possible circular locking dependency detected 5.3.0-rc2+ #23 Not tainted ------------------------------------------------------ syz-executor.2/20386 is trying to acquire lock: 00000000772249c6 (rio500_mutex){+.+.}, at: open_rio+0x16/0xc0 drivers/usb/misc/rio500.c:64 but task is already holding lock: 00000000d3e8f4b9 (minor_rwsem){++++}, at: usb_open+0x23/0x270 drivers/usb/core/file.c:39 which lock already depends on the new lock. The problem is that the driver's open_rio() routine is called while the usbcore's minor_rwsem is locked for reading, and it acquires the rio500_mutex; whereas conversely, probe_rio() and disconnect_rio() first acquire the rio500_mutex and then call usb_register_dev() or usb_deregister_dev(), which lock minor_rwsem for writing. The correct ordering of acquisition should be: minor_rwsem first, then rio500_mutex (since the locking in open_rio() cannot be changed). Thus, the probe and disconnect routines should avoid holding rio500_mutex while doing their registration and deregistration. This patch adjusts the code in those two routines to do just that. It also relies on the fact that the probe and disconnect routines are protected by the device mutex, so the initial test of rio->present needs no extra locking. Reported-by: syzbot+7bbcbe9c9ff0cd49592a@syzkaller.appspotmail.com Signed-off-by:Alan Stern <stern@rowland.harvard.edu> Fixes: d710734b ("USB: rio500: simplify locking") Acked-by:
Oliver Neukum <oneukum@suse.com> CC: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1908081329240.1319-100000@iolanthe.rowland.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Oliver Neukum authored
Admitting that there can be only one device allows us to drop any pretense about locking one device or a table of devices. Signed-off-by:
-
Chunfeng Yun authored
Because extcon is not allowed for new bindings, and the dual role switch is supported by USB Role Switch, especially for Type-C drivers, so register a USB Role Switch to support the new way Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1567070558-29417-12-git-send-email-chunfeng.yun@mediatek.comSigned-off-by:
-
Chunfeng Yun authored
Due to the requirement of usb-connector.txt binding, the old way using extcon to support USB Dual-Role switch is now deprecated when use Type-B connector. This patch introduces a USB GPIO based connection detection driver, used to support Type-B connector which typically uses an input GPIO to detect USB ID pin, and try to replace the function provided by the extcon-usb-gpio driver Signed-off-by:
Nagarjuna Kristam <nkristam@nvidia.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/1567070558-29417-11-git-send-email-chunfeng.yun@mediatek.comSigned-off-by:
-
Chunfeng Yun authored
Create Kconfig file for USB common core, and move USB_LED_TRIG and USB_ULPI_BUS configs into the new file from the parent Kconfig, it will help to add new configs later. Signed-off-by:
-
Chunfeng Yun authored
when the USB host controller is the parent of the connector, usually type-B, sometimes don't need the graph, so we should check whether it's parent registers usb-role-switch or not firstly, and get it if exists. Suggested-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
Greg Kroah-Hartman authored
The lookup helpers are needed here. Signed-off-by: -
Heikki Krogerus authored
The fwnode_usb_role_switch_get() function is exactly the same as usb_role_switch_get(), except that it takes struct fwnode_handle as parameter instead of struct device. Signed-off-by:
Biju Das <biju.das@bp.renesas.com> Link: https://lore.kernel.org/r/1567070558-29417-8-git-send-email-chunfeng.yun@mediatek.comSigned-off-by:
-
Heikki Krogerus authored
The fwnode_connection_find_match() function is exactly the same as device_connection_find_match(), except it takes struct fwnode_handle as parameter instead of struct device. That allows locating device connections before the device entries have been created. Signed-off-by:
-
Yu Chen authored
This patch adds stubs for the exiting functions while CONFIG_USB_ROLE_SWITCH does not enabled. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: John Stultz <john.stultz@linaro.org> Reviewed-by:
Yu Chen <chenyu56@huawei.com> Signed-off-by:
-
Chunfeng Yun authored
Now the USB Role Switch is supported, so add properties about it, and modify some description related. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1567070558-29417-5-git-send-email-chunfeng.yun@mediatek.comSigned-off-by:
-
Chunfeng Yun authored
It's used to support dual role switch via GPIO when use Type-B receptacle, typically the USB ID pin is connected to an input GPIO, and also used to enable/disable device when the USB Vbus pin is connected to an input GPIO. Signed-off-by:
-
Chunfeng Yun authored
Add id-gpios, vbus-gpios, vbus-supply and pinctrl properties for usb-b-connector Signed-off-by:
-
Chunfeng Yun authored
Add a property usb-role-switch to tell the driver that use USB Role Switch framework to handle the role switch, it's useful when the driver has already supported other ways, such as extcon framework etc. Cc: Biju Das <biju.das@bp.renesas.com> Cc: Yu Chen <chenyu56@huawei.com> Signed-off-by:
-
Suwan Kim authored
There are bugs on vhci with usb 3.0 storage device. In USB, each SG list entry buffer should be divisible by the bulk max packet size. But with native SG support, this problem doesn't matter because the SG buffer is treated as contiguous buffer. But without native SG support, USB storage driver breaks SG list into several URBs and the error occurs because of a buffer size of URB that cannot be divided by the bulk max packet size. The error situation is as follows. When USB Storage driver requests 31.5 KB data and has SG list which has 3584 bytes buffer followed by 7 4096 bytes buffer for some reason. USB Storage driver splits this SG list into several URBs because VHCI doesn't support SG and sends them separately. So the first URB buffer size is 3584 bytes. When receiving data from device, USB 3.0 device sends data packet of 1024 bytes size because the max packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes. But the first URB buffer has only 3584 bytes buffer size. So host controller terminates the transfer even though there is more data to receive. So, vhci needs to support SG transfer to prevent this error. In this patch, vhci supports SG regardless of whether the server's host controller supports SG or not, because stub driver splits SG list into several URBs if the server's host controller doesn't support SG. To support SG, vhci sets URB_DMA_MAP_SG flag in urb->transfer_flags if URB has SG list and this flag will tell stub driver to use SG list. After receiving urb from stub driver, vhci clear URB_DMA_MAP_SG flag to avoid unnecessary DMA unmapping in HCD. vhci sends each SG list entry to stub driver. Then, stub driver sees the total length of the buffer and allocates SG table and pages according to the total buffer length calling sgl_alloc(). After stub driver receives completed URB, it again sends each SG list entry to vhci. If the server's host controller doesn't support SG, stub driver breaks a single SG request into several URBs and submits them to the server's host controller. When all the split URBs are completed, stub driver reassembles the URBs into a single return command and sends it to vhci. Moreover, in the situation where vhci supports SG, but stub driver does not, or vice versa, usbip works normally. Because there is no protocol modification, there is no problem in communication between server and client even if the one has a kernel without SG support. In the case of vhci supports SG and stub driver doesn't, because vhci sends only the total length of the buffer to stub driver as it did before the patch applied, stub driver only needs to allocate the required length of buffers using only kmalloc() regardless of whether vhci supports SG or not. But stub driver has to allocate buffer with kmalloc() as much as the total length of SG buffer which is quite huge when vhci sends SG request, so it has overhead in buffer allocation in this situation. If stub driver needs to send data buffer to vhci because of IN pipe, stub driver also sends only total length of buffer as metadata and then sends real data as vhci does. Then vhci receive data from stub driver and store it to the corresponding buffer of SG list entry. And for the case of stub driver supports SG and vhci doesn't, since the USB storage driver checks that vhci doesn't support SG and sends the request to stub driver by splitting the SG list into multiple URBs, stub driver allocates a buffer for each URB with kmalloc() as it did before this patch. * Test environment Test uses two difference machines and two different kernel version to make mismatch situation between the client and the server where vhci supports SG, but stub driver does not, or vice versa. All tests are conducted in both full SG support that both vhci and stub support SG and half SG support that is the mismatch situation. Test kernel version is 5.3-rc6 with commit "usb: add a HCD_DMA flag instead of guestimating DMA capabilities" to avoid unnecessary DMA mapping and unmapping. - Test kernel version - 5.3-rc6 with SG support - 5.1.20-200.fc29.x86_64 without SG support * SG support test - Test devices - Super-speed storage device - SanDisk Ultra USB 3.0 - High-speed storage device - SMI corporation USB 2.0 flash drive - Test description Test read and write operation of mass storage device that uses the BULK transfer. In test, the client reads and writes files whose size is over 1G and it works normally. * Regression test - Test devices - Super-speed device - Logitech Brio webcam - High-speed device - Logitech C920 HD Pro webcam - Full-speed device - Logitech bluetooth mouse - Britz BR-Orion speaker - Low-speed device - Logitech wired mouse - Test description Moving and click test for mouse. To test the webcam, use gnome-cheese. To test the speaker, play music and video on the client. All works normally. * VUDC compatibility test VUDC also works well with this patch. Tests are done with two USB gadget created by CONFIGFS USB gadget. Both use the BULK pipe. 1. Serial gadget 2. Mass storage gadget - Serial gadget test Serial gadget on the host sends and receives data using cat command on the /dev/ttyGS<N>. The client uses minicom to communicate with the serial gadget. - Mass storage gadget test After connecting the gadget with vhci, use "dd" to test read and write operation on the client side. Read - dd if=/dev/sd<N> iflag=direct of=/dev/null bs=1G count=1 Write - dd if=<my file path> iflag=direct of=/dev/sd<N> bs=1G count=1 Signed-off-by:Suwan Kim <suwan.kim027@gmail.com> Acked-by:
Shuah khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20190828032741.12234-1-suwan.kim027@gmail.comSigned-off-by:
-
Saranya Gopal authored
Enable static DRD mode in Intel platforms which guarantees successful role switch all the time. This fixes issues like software role switch failure after cold boot and issue with role switch when USB 3.0 cable is used. But, do not enable static DRD mode for Cherrytrail devices which rely on firmware for role switch. Signed-off-by:
Saranya Gopal <saranya.gopal@intel.com> Signed-off-by:
Balaji Manoharan <m.balaji@intel.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Tested-by:
-
Saranya Gopal authored
In platforms like Cherrytrail, 'SW switch enable' bit should not be enabled for role switch. This patch adds a property to Intel USB Role Switch platform driver to denote that SW switch should be disabled in Cherrytrail devices. Signed-off-by:
-
Marek Szyprowski authored
Calls to USB2 generic PHY calibrate() method has been moved to HCD core, which now successfully handles generic PHYs and their calibration after every HCD reset. This fixes all the timing issues related to PHY calibration done directly from DWC3 driver: incorrect operation after system suspend/resume or USB3.0 detection failure when XHCI-plat driver compiled as separate module. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Anand Moon <linux.amoon@gmail.com> Tested-by:
Jochen Sprickerhof <jochen@sprickerhof.de> Acked-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Link: https://lore.kernel.org/r/20190829053028.32438-3-m.szyprowski@samsung.comSigned-off-by:
-
Marek Szyprowski authored
Some PHYs (for example Exynos5 USB3.0 DRD PHY) require calibration to be done after every USB HCD reset. Generic PHY framework has been already extended with phy_calibrate() function in commit 36914111 ("drivers: phy: add calibrate method"). This patch adds support for it to generic PHY handling code in USB HCD core. Signed-off-by:
-
Chuhong Yuan authored
Use devm_reset_controller_register to get rid of manual unregistration. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Link: https://lore.kernel.org/r/20190902014323.27588-1-hslester96@gmail.comSigned-off-by:
-
Yoshihiro Shimoda authored
This patch uses xhci_plat_priv.quirks to simplify. The previous code had conditions to set some quirks in xhci_rcar_init_quirk(). But, the xhci_rcar_init_quirk() is called at the same conditions. So, no behavior change. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/1567425698-27560-4-git-send-email-yoshihiro.shimoda.uh@renesas.comSigned-off-by:
-
Yoshihiro Shimoda authored
To avoid copy-and-paste setting of xhci_plat_priv for R-Car SoCs, this patch add a helper macro SET_XHCI_PLAT_PRIV_FOR_RCAR. Signed-off-by:
-
Yoshihiro Shimoda authored
To simplify adding xhci->quirks instead of the .init_quirk() function, this patch adds a new parameter "quirks" into the struct xhci_plat_priv. Signed-off-by:
-
Ikjoon Jang authored
Xhci re-enables a slot on transaction error in set_address using xhci_disable_slot() + xhci_alloc_dev(). But in this case, xhci_alloc_dev() creates debugfs entries upon an existing device without cleaning up old entries, thus memory leaks. So this patch simply moves calling xhci_debugfs_free_dev() from xhci_free_dev() to xhci_disable_slot(). [added "possible" to header as this is about failure codepath -Mathias] Signed-off-by:
Ikjoon Jang <ikjn@chromium.org> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1567172356-12915-5-git-send-email-mathias.nyman@linux.intel.comSigned-off-by:
-
Mathias Nyman authored
Software can set a Transfer State Preserve (TSP) flag to maintain data toggle and sequence number when issuing a reset endpoint command. xhci driver is using TSP for soft retry, we want to show TSP usage in tracing as well Signed-off-by:
-
Christophe JAILLET authored
There is no need to use GFP_ATOMIC to allocate 'req'. GFP_KERNEL should be enough and is already used for another allocation juste a few lines below. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
If the 'kmalloc()' fails, we need to undo the previous 'dbc_alloc_request()' call. Because of the more similar function name, it is more logical to use 'dbc_free_request()' instead of 'xhci_dbc_free_req()'. Both are equivalent here because: static void xhci_dbc_free_req(struct dbc_ep *dep, struct dbc_request *req) { kfree(req->buf); dbc_free_request(dep, req); } and 'req->buf' is known to be NULL at this point Signed-off-by: -
Colin Ian King authored
There is a spelling mistake in a dev_dbg message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20190903120710.30128-1-colin.king@canonical.comSigned-off-by:
-
Colin Ian King authored
Currently the check on a non-zero return code in ret is false because ret has been initialized to zero. I believe that ret should be assigned to the return from the call to readl_poll_timeout_atomic before the check on ret. Since ret is being re-assinged the original initialization of ret to zero can be removed. Addresses-Coverity: ("'Constant' variable guards dead code") Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver") Signed-off-by: -
Colin Ian King authored
In the case where an allocation fails for priv_ep ret is assigned -ENOMEM and the code exits via the exit path 'err'. The exit path returns -ENOMEM without using variable ret, so the assingment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
YueHaibing authored
If CONFIG_REGMAP_I2C is not set, building fails: drivers/usb/typec/tps6598x.o: In function `tps6598x_probe': tps6598x.c:(.text+0x5f0): undefined reference to `__devm_regmap_init_i2c' Select REGMAP_I2C to fix this. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 0a4c005b ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/usb/cdns3/gadget.c: In function '__cdns3_gadget_init': drivers/usb/cdns3/gadget.c:2665:23: warning: variable 'priv_dev' set but not used [-Wunused-but-set-variable] drivers/usb/cdns3/gadget.c: In function cdns3_start_all_request: drivers/usb/cdns3/gadget.c:357:24: warning: variable priv_req set but not used [-Wunused-but-set-variable] They are never used, so can be removed. Reported-by:
-
YueHaibing authored
drivers/usb/cdns3/ep0.c: In function cdns3_ep0_feature_handle_device: drivers/usb/cdns3/ep0.c:290:6: warning: variable wIndex set but not used [-Wunused-but-set-variable] drivers/usb/cdns3/ep0.c:289:6: warning: variable wValue set but not used [-Wunused-but-set-variable] wIndex is never used, so remove it. wValue should be use in the switch statement. Reported-by:
-
Christoph Hellwig authored
Now that these drivers use the usb localmem pool there is no need to select DMA_DECLARE_COHERENT. Signed-off-by:
Christoph Hellwig <hch@lst.de> Tested-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20190903084615.19161-7-hch@lst.deSigned-off-by:
-
Christoph Hellwig authored
These wrappers have never seen use and have been commented out for a long time. Remove them for good. Signed-off-by:
-
Christoph Hellwig authored
Now that we have the local memory pool implemented there is no need to use dma_declare_coherent_memory. Signed-off-by:
-
Christoph Hellwig authored
The dma_mask on its own doesn't mean much. Instead check for the actual flag. Signed-off-by:
-
Christoph Hellwig authored
This driver doesn't support normal DMA, only direct access to its local memory. Remove the HCD_DMA flag to properly express that fact. Fixes: 7b81cb6b ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities") Signed-off-by:
-
Christoph Hellwig authored
This driver doesn't support normal DMA, only direct access to its local memory. Remove the HCD_DMA flag to properly express that fact. Fixes: 7b81cb6b ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities") Reported-by:
-
- 02 Sep, 2019 1 commit
-
-
Greg Kroah-Hartman authored
We need the usb fixes in here for testing Signed-off-by:
-
