- 05 Oct, 2023 1 commit
-
-
Randy Li authored
usb_buffer_map_sg() and usb_buffer_unmap_sg() have no definition since the beginning of v5.4. The rest are gone from 2.6.12. Signed-off-by:
Randy Li <ayaka@soulik.info> Link: https://lore.kernel.org/r/20230914172336.18761-2-ayaka@soulik.infoSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 Oct, 2023 1 commit
-
-
Greg Kroah-Hartman authored
This reverts commit 685dbd1b. It is reported to break the build in linux-next so revert it for now. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/r/20231004132247.01c3bfeb@canb.auug.org.au Cc: Rohit Agarwal <quic_rohiagar@quicinc.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
- 02 Oct, 2023 38 commits
-
-
Andrey Konovalov authored
Return USB_GADGET_DELAYED_STATUS from the setup() callback for 0-length transfers as a workaround to stop some UDC drivers (e.g. dwc3) from automatically proceeding with the status stage. This workaround should be removed once all UDC drivers are fixed to always delay the status stage until a response is queued to EP0. Reviewed-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Andrey Konovalov <andreyknvl@gmail.com> Link: https://lore.kernel.org/r/a8d2b91f9890dc21daa359183e84879ff4525180.1693237258.git.andreyknvl@gmail.comSigned-off-by:
-
Andrey Konovalov authored
Return USB_GADGET_DELAYED_STATUS from the setup() callback for 0-length transfers as a workaround to stop some UDC drivers (e.g. dwc3) from automatically proceeding with the status stage. This workaround should be removed once all UDC drivers are fixed to always delay the status stage until a response is queued to EP0. Signed-off-by:
-
Andrey Konovalov authored
USB_GADGET_DELAYED_STATUS was introduced in commit 1b9ba000 ("usb: gadget: composite: Allow function drivers to pause control transfers"). It was initially intended for the composite framework to allow delaying completing the status stage of a SET_CONFIGURATION request until all functions are ready. Unfortunately, that commit had an unintended side-effect of returning USB_GADGET_DELAYED_STATUS from the ->setup() call of the composite framework gadget driver. As a result of this and the incomplete documentation, some UDC drivers started relying on USB_GADGET_DELAYED_STATUS to decide when to avoid autocompleting the status stage for 0-length control transfers. dwc3 was the first in commit 5bdb1dcc ("usb: dwc3: ep0: handle delayed_status again"). And a number of other UDC drivers followed later, probably relying on the dwc3 behavior as a reference. Unfortunately, this violated the interface between the UDC and the gadget driver for 0-length control transfers: the UDC driver must only proceed with the status stage for a 0-length control transfer once the gadget driver queued a response to EP0. As a result, a few gadget drivers are partially broken when used with a UDC that only delays the status stage for 0-length transfers when USB_GADGET_DELAYED_STATUS is returned from the setup() callback. This includes Raw Gadget and GadgetFS. For FunctionFS, a workaround was added in commit 946ef68a ("usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS") and commit 4d644abf ("usb: gadget: f_fs: Only return delayed status when len is 0"). The proper solution to this issue would be to contain USB_GADGET_DELAYED_STATUS within the composite framework and make all UDC drivers to not complete the status stage for 0-length requests on their own. Unfortunately, there is quite a few UDC drivers that need to get fixed and the required changes for some of them are not trivial. For now, update the comments to clarify that USB_GADGET_DELAYED_STATUS must not be used by the UDC drivers. The following two commits also add workarounds to Raw Gadget and GadgetFS to make them compatible with the broken UDC drivers until they are fixed. Acked-by:
-
Yue Haibing authored
Commit e9b29ffc ("USB: add Cypress c67x00 OTG controller HCD driver") declared but never implemented this. Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20230825091518.22180-1-yuehaibing@huawei.comSigned-off-by:
-
Heikki Krogerus authored
Exposing the value of the field as is. The Peak Current value has to be interpreted as described in Table 6-10 (Fixed Power Source Peak Current Capability) of the USB Power Delivery Specification, but that interpretation will be done in user space, not in kernel. Suggested-by:
Douglas Gilbert <dgilbert@interlog.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231002142240.2641962-1-heikki.krogerus@linux.intel.comSigned-off-by:
-
Jerome Brunet authored
Add support for the gl3510 4 ports USB3.1 hub. This allows to control its reset pins with a gpio. No public documentation is available for this hub. Using the same reset duration as the gl852g which seems OK. Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20231002122909.2338049-3-jbrunet@baylibre.comSigned-off-by:
-
Jerome Brunet authored
Add gl3510 USB 3 root hub device id Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Michael Wu authored
The USB Type-C Cable and Connector Specification defines the wire connections for the USB Type-C to USB 2.0 Standard-A cable assembly (Release 2.2, Chapter 3.5.2). The Notes says that Pin A5 (CC) of the USB Type-C plug shall be connected to Vbus through a resister Rp. However, there is a large amount of such double Rp connected to Vbus non-standard cables which produced by UGREEN circulating on the market, and it can affects the normal operations of the state machine easily, especially to CC1 and CC2 be pulled up at the same time. In fact, we can regard those cables as sink to avoid abnormal state. Message as follow: [ 58.900212] VBUS on [ 59.265433] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [ 62.623308] CC1: 3 -> 0, CC2: 3 -> 0 [state TOGGLING, polarity 0, disconnected] [ 62.625006] VBUS off [ 62.625012] VBUS VSAFE0V Signed-off-by:
Michael Wu <michael@allwinnertech.com> Reviewed-by:
-
Chunfeng Yun authored
Calculate the IN/OUT budget separately to improve the bandwidth schedule, meanwhile should avoid Start-Split token overlap between IN and OUT endpoints, and take into account the FS/LS bandwidth boundary in each microframe and also in each FS frame. Calculate the budget for SS of OUT eps and CS of IN eps, but not include extra-cs, and always add at most extra-cs allowed. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20230830122820.18859-2-chunfeng.yun@mediatek.comSigned-off-by:
-
Chunfeng Yun authored
In order to estimate when fs/ls transactions appear on a downstream bus, the host must calculate a best case full-speed budget, use a table to track how many bytes occure in each microframe. This patch is prepared for introducing an improved bandwidth scheduling. Signed-off-by:
-
Fabio Estevam authored
imx27.dtsi describes its usb nodes as: compatible = "fsl,imx27-usb"; Adjust the bindings to allow it and avoid the following schema warning: usb@10024000: compatible: 'oneOf' conditional failed, one must be fixed: ['fsl,imx27-usb'] is too short Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
-
Niklas Schnelle authored
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. With the AMD quirk handled USB PCI quirks still use inw() in uhci_check_and_reset_hc() and thus indirectly in quirk_usb_handoff_uhci(). Handle this by conditionally compiling uhci_check_and_reset_hc() and stubbing out quirk_usb_handoff_uhci() when HAS_IOPORT is not available. Co-developed-by:
Arnd Bergmann <arnd@kernel.org> Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Link: https://lore.kernel.org/r/20230911125653.1393895-4-schnelle@linux.ibm.comSigned-off-by:
-
Niklas Schnelle authored
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. In the pci-quirks case the I/O port acceses are used in the quirks for several AMD south bridges, Add a config option for the AMD quirks to depend on HAS_IOPORT and #ifdef the quirk code. Co-developed-by:
-
Niklas Schnelle authored
A follow on patch will introduce CONFIG_USB_PCI_AMD governing the AMD quirk and adding its compile time dependency on HAS_IOPORT. In order to minimize the number of #ifdefs in C files and make that patch easier to read first group the code together. This is pure code movement no functional change is intended. Co-developed-by:
-
Jinjie Ruan authored
Convert list_for_each() to list_for_each_entry() so that the p/pos list_head pointer and list_entry() call are no longer needed, which can reduce a few lines of code. No functional changed. Signed-off-by:
Jinjie Ruan <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20230830085658.527752-1-ruanjinjie@huawei.comSigned-off-by:
-
Michał Mirosław authored
Convert all error exits from probe() to dev_err_probe(). Acked-by:
Peter Chen <peter.chen@kernel.org> Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/43d03aad1c394d9995f69d13ca1176f9ff8a8dab.1695934946.git.mirq-linux@rere.qmqm.plSigned-off-by:
-
Michał Mirosław authored
The USB host on Tegra3 works with 32-bit alignment. Previous code tried to align the buffer, but it did align the wrapper struct instead, so the buffer was at a constant offset of 8 bytes (two pointers) from expected alignment. Since kmalloc() guarantees at least 8-byte alignment already, the alignment-extending is removed. Fixes: fc53d527 ("usb: chipidea: tegra: Support host mode") Signed-off-by:
-
Michał Mirosław authored
Tegra USB controllers seem to issue DMA in full 32-bit words only and thus may overwrite unevenly-sized buffers. One such occurrence is detected by SLUB when receiving a reply to a 1-byte buffer (below). Fix this by allocating a bounce buffer also for buffers with sizes not a multiple of 4. ============================================================================= BUG kmalloc-64 (Tainted: G B ): kmalloc Redzone overwritten ----------------------------------------------------------------------------- 0x8555cd02-0x8555cd03 @offset=3330. First byte 0x0 instead of 0xcc Allocated in usb_get_status+0x2b/0xac age=1 cpu=3 pid=41 __kmem_cache_alloc_node+0x12f/0x1e4 __kmalloc+0x33/0x8c usb_get_status+0x2b/0xac hub_probe+0x5e9/0xcec usb_probe_interface+0xbf/0x21c really_probe+0xa5/0x2c4 __driver_probe_device+0x75/0x174 driver_probe_device+0x31/0x94 __device_attach_driver+0x65/0xc0 bus_for_each_drv+0x4b/0x74 __device_attach+0x69/0x120 bus_probe_device+0x65/0x6c device_add+0x48b/0x5f8 usb_set_configuration+0x37b/0x6b4 usb_generic_driver_probe+0x37/0x68 usb_probe_device+0x35/0xb4 Slab 0xbf622b80 objects=21 used=18 fp=0x8555cdc0 flags=0x800(slab|zone=0) Object 0x8555cd00 @offset=3328 fp=0x00000000 Redzone 8555ccc0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 8555ccd0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 8555cce0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 8555ccf0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Object 8555cd00: 01 00 00 00 cc cc cc cc cc cc cc cc cc cc cc cc ................ Object 8555cd10: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Object 8555cd20: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Object 8555cd30: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 8555cd40: cc cc cc cc .... Padding 8555cd74: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ CPU: 3 PID: 41 Comm: kworker/3:1 Tainted: G B 6.6.0-rc1mq-00118-g59786f827ea1 #1115 Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) Workqueue: usb_hub_wq hub_event [<8010ca28>] (unwind_backtrace) from [<801090a5>] (show_stack+0x11/0x14) [<801090a5>] (show_stack) from [<805da2fb>] (dump_stack_lvl+0x4d/0x7c) [<805da2fb>] (dump_stack_lvl) from [<8026464f>] (check_bytes_and_report+0xb3/0xe4) [<8026464f>] (check_bytes_and_report) from [<802648e1>] (check_object+0x261/0x290) [<802648e1>] (check_object) from [<802671b1>] (free_to_partial_list+0x105/0x3f8) [<802671b1>] (free_to_partial_list) from [<80268613>] (__kmem_cache_free+0x103/0x128) [<80268613>] (__kmem_cache_free) from [<80425a67>] (usb_get_status+0x73/0xac) [<80425a67>] (usb_get_status) from [<80421b31>] (hub_probe+0x5e9/0xcec) [<80421b31>] (hub_probe) from [<80428bbb>] (usb_probe_interface+0xbf/0x21c) [<80428bbb>] (usb_probe_interface) from [<803ee13d>] (really_probe+0xa5/0x2c4) [<803ee13d>] (really_probe) from [<803ee3d1>] (__driver_probe_device+0x75/0x174) [<803ee3d1>] (__driver_probe_device) from [<803ee501>] (driver_probe_device+0x31/0x94) usb 1-1: device descriptor read/8, error -71 Fixes: fc53d527 ("usb: chipidea: tegra: Support host mode") Signed-off-by:
-
Rohit Agarwal authored
Add support for USB3 QMP PHY found in SDX75 platform. Signed-off-by:
Rohit Agarwal <quic_rohiagar@quicinc.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/1695359525-4548-6-git-send-email-quic_rohiagar@quicinc.comSigned-off-by:
-
Rohit Agarwal authored
Document the SDX75 dwc3 compatible. Signed-off-by:
-
Rohit Agarwal authored
SDX65 has 5 clocks so mention in the bindings. Fixes: 16946a60 ("dt-bindings: usb: qcom,dwc3: fix clock matching") Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1695359525-4548-4-git-send-email-quic_rohiagar@quicinc.comSigned-off-by:
-
Rohit Agarwal authored
Add dt-bindings for USB3 PHY found on Qualcomm SDX75. Signed-off-by:
-
Rohit Agarwal authored
Add a dt-bindings compatible string for the SDX75 SoC that uses Synopsis eUSB2 PHY. Signed-off-by:
-
Stanley Chang authored
In Synopsys's dwc3 data book: To avoid underrun and overrun during the burst, in a high-latency bus system (like USB), threshold and burst size control is provided through GTXTHRCFG and GRXTHRCFG registers. By default, USB TX and RX threshold are not enabled. To enable TX or RX threshold, both packet threshold count and max burst size properties must be set to a valid non-zero value. In Realtek DHC SoC, DWC3 USB 3.0 uses AHB system bus. When dwc3 is connected with USB 2.5G Ethernet, there will be overrun problem. Therefore, setting TX/RX thresholds can avoid this issue. Signed-off-by:
Stanley Chang <stanley_chang@realtek.com> Reviewed-by:
-
Stanley Chang authored
In Synopsys's dwc3 data book: To avoid underrun and overrun during the burst, in a high-latency bus system (like USB), threshold and burst size control is provided through GTXTHRCFG and GRXTHRCFG registers. In Realtek DHC SoC, DWC3 USB 3.0 uses AHB system bus. When dwc3 is connected with USB 2.5G Ethernet, there will be overrun problem. Therefore, setting TX/RX thresholds can avoid this issue. Signed-off-by:
Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20230912041904.30721-1-stanley_chang@realtek.comSigned-off-by:
-
Stanley Chang authored
Document the DWC3 USB bindings for Realtek SoCs. Signed-off-by:
-
Stanley Chang authored
Realtek DHC RTD SoCs integrate dwc3 IP and has some customizations to support different generations of SoCs. The RTD1619b subclass SoC only supports USB 2.0 from dwc3. The driver can set a maximum speed to support this. Add role switching function, that can switch USB roles through other drivers, or switch USB roles through user space through set /sys/class/usb_role/. Signed-off-by:
-
Utkarsh Patel authored
Mux agent driver can configure cable details such as cable type and cable speed received as a part of displayport configuration to support Displayport Alternate mode 2.1. Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Utkarsh Patel <utkarsh.h.patel@intel.com> Link: https://lore.kernel.org/r/20230920023243.2494410-6-utkarsh.h.patel@intel.comSigned-off-by:
-
Utkarsh Patel authored
Displayport Alternatemode 2.1 requires cable capabilities such as cable signalling, cable type, DPAM version which then will be used by mux driver for displayport configuration. These capabilities can be derived from the Cable VDO. Acked-by:
Prashant Malani <pmalani@chromium.org> Signed-off-by:
-
Utkarsh Patel authored
Added a helper macro to get the Type C cable speed when provided the cable VDO. Reviewed-by:
-
Utkarsh Patel authored
As per USB Type-C Connector specification v2.2 section F.2.6, BIT25 represents Active or Passive cable. Added BIT25 defination to the Thunderbolt 3 cable discover mode VDO. Reviewed-by:
-
Utkarsh Patel authored
Displayport Alternate mode 2.1 requires configuration for additional cable details such as signalling for cable, UHBR13.5 Support, Cable type and DPAM version. These details can be used with mux drivers to configure SOP DP configuration for Displayport Alternate mode 2.1. This change also includes pertinent cable signalling support in displayport alternate mode. Reviewed-by:
-
Michael Grzeschik authored
The uvc_video_enable function is calling cancel_work_sync which will be blocking as long as new requests will be queued with the while loop. To ensure an earlier stop in the pumping loop in this particular case we rework the worker to requeue itself on every requests. Since the worker is already running prioritized, the scheduling overhad did not have real impact on the performance. Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20230911140530.2995138-4-m.grzeschik@pengutronix.deSigned-off-by:
-
Michael Grzeschik authored
The uvc_video_enable function of the uvc-gadget driver is dequeing and immediately deallocs all requests on its disable codepath. This is not save since the dequeue function is async and does not ensure that the requests are left unlinked in the controller driver. By adding the ep_free_request into the completion path of the requests we ensure that the request will be properly deallocated. Signed-off-by:
-
Michael Grzeschik authored
Since the uvc-video gadget driver is using the v4l2 interface, the streamon and streamoff can be triggered at any times. To ensure that the pump worker will be closed as soon the userspace is calling streamoff we synchronize the state of the gadget ensuring the pump worker to bail out. Signed-off-by:
-
Krishna Kurapati authored
In the event gadget_connect call (which invokes pullup) fails, propagate the error to udc bind operation which in turn sends the error to configfs. The userspace can then retry enumeration if it chooses to. Signed-off-by:
Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by:
-
Jia-Ju Bai authored
In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n"); goto out; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags); When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference. This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5. To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic. Fixes: 33ad261a ("usb: dwc2: host: spinlock urb_enqueue") Signed-off-by:Jia-Ju Bai <baijiaju@buaa.edu.cn> Link: https://lore.kernel.org/r/20230926024404.832096-1-baijiaju@buaa.edu.cnSigned-off-by:
-
Wolfram Sang authored
There is a SPDX entry, so we can remove the boilerplate. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230922064551.4663-1-wsa+renesas@sang-engineering.comSigned-off-by:
-
