- 05 Oct, 2023 12 commits
-
-
Greg Kroah-Hartman authored
This reverts commit 3a63f86c. Based on review comments, it was applied too soon and needs more work. Reported-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20231005081716.GA13853@pendragon.ideasonboard.com Cc: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit 52a39f2c. Based on review comments, it was applied too soon and needs more work. Reported-by:
-
Greg Kroah-Hartman authored
This reverts commit bb00788b. Based on review comments, it was applied too soon and needs more work. Reported-by:
-
Neil Armstrong authored
Specify orientation GPIO to the PMIC GLINK node. Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20231002-topic-sm8550-upstream-type-c-orientation-v2-4-125410d3ff95@linaro.orgSigned-off-by:
-
Neil Armstrong authored
Specify orientation GPIO in the PMIC GLINK node. Signed-off-by:
-
Neil Armstrong authored
On SM8550, the non-altmode orientation is not given anymore within altmode events, even with USB SVIDs events. On the other side, the Type-C connector orientation is correctly reported by a signal from the PMIC. Take this gpio signal when we detect some Type-C port activity to notify any Type-C switches tied to the Type-C port connectors. Acked-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by:
-
Neil Armstrong authored
dt-bindings: soc: qcom: qcom,pmic-glink: add a gpio used to determine the Type-C port plug orientation On SM8450 and SM8550 based platforms, the Type-C plug orientation is given on a GPIO line for each connector which are set by the PMIC(s). Document this optional Type-C connector property, and take the assumption an active level represents an inverted/flipped orientation. Signed-off-by:
-
Swarup Laxman Kotiaklapudi authored
Avoid a kernel-doc warning by documenting it: drivers/usb/dwc3/core.h:1343: warning: Function parameter or member 'gfladj_refclk_lpm_sel' not described in 'dwc3' Fixes: a6fc2f1b ("usb: dwc3: core: add gfladj_refclk_lpm_sel quirk") Signed-off-by:Swarup Laxman Kotiaklapudi <swarupkotikalapudi@gmail.com> Acked-by:
Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20231002210137.209382-1-swarupkotikalapudi@gmail.comSigned-off-by:
-
James Gruber authored
Add "c_terminal_type" and "p_terminal_type" configfs entries in order to allow the user to change the capture and playback terminal type codes. These fields affect the type of audio device that Windows detects, so being able to modify this is useful when it would be advantageous for a gadget to be detected as something other than a generic speaker/microphone. The fields default to microphone for the capture type field and speaker for the playback type field as was the case before. Signed-off-by:
James Gruber <jimmyjgruber@gmail.com> Link: https://lore.kernel.org/r/20230914222746.155126-1-jimmyjgruber@gmail.comSigned-off-by:
-
Fabio Estevam authored
Add a compatible entry for the NXP CBDTU02043 GPIO-based mux hardware used for connecting, disconnecting and switching orientation of the SBU lines in USB Type-C applications. CBTU02043 datasheet: https://www.nxp.com/docs/en/data-sheet/CBTU02043.pdfSigned-off-by:
Fabio Estevam <festevam@denx.de> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230927123511.45085-1-festevam@gmail.comSigned-off-by:
-
Randy Li authored
We should not hide the recommend APIs in a obscure place. Signed-off-by:
Randy Li <ayaka@soulik.info> Link: https://lore.kernel.org/r/20230914172336.18761-3-ayaka@soulik.infoSigned-off-by:
-
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:
-
- 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 27 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:
-
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:
-
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:
-
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:
-
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:
-
