summaryrefslogtreecommitdiffstats
path: root/drivers/usb
Commit message (Collapse)AuthorAgeFilesLines
...
| * usb: dwc: ep0: Update request status in dwc3_ep0_stall_restartUttkarsh Aggarwal2024-01-041-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current implementation blocks the running operations when Plug-out and Plug-In is performed continuously, process gets stuck in dwc3_thread_interrupt(). Code Flow: CPU1 ->Gadget_start ->dwc3_interrupt ->dwc3_thread_interrupt ->dwc3_process_event_buf ->dwc3_process_event_entry ->dwc3_endpoint_interrupt ->dwc3_ep0_interrupt ->dwc3_ep0_inspect_setup ->dwc3_ep0_stall_and_restart By this time if pending_list is not empty, it will get the next request on the given list and calls dwc3_gadget_giveback which will unmap request and call its complete() callback to notify upper layers that it has completed. Currently dwc3_gadget_giveback status is set to -ECONNRESET, whereas it should be -ESHUTDOWN based on condition if not dwc->connected is true. Cc: <stable@vger.kernel.org> Fixes: d742220b3577 ("usb: dwc3: ep0: giveback requests on stall_and_restart") Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com> Link: https://lore.kernel.org/r/20231222094704.20276-1-quic_uaggarwa@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: ueagle-atm: Use wait_event_freezable_timeout() in uea_wait()Kevin Hao2024-01-041-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A freezable kernel thread can enter frozen state during freezing by either calling try_to_freeze() or using wait_event_freezable() and its variants. So for the following snippet of code in a kernel thread loop: wait_event_interruptible_timeout(); try_to_freeze(); We can change it to a simple wait_event_freezable_timeout() and then eliminate a function call. Signed-off-by: Kevin Hao <haokexin@gmail.com> Link: https://lore.kernel.org/r/20231218074730.1898699-1-haokexin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: dwc3: gadget: Handle EP0 request dequeuing properlyWesley Cheng2024-01-041-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current EP0 dequeue path will share the same as other EPs. However, there are some special considerations that need to be made for EP0 transfers: - EP0 transfers never transition into the started_list - EP0 only has one active request at a time In case there is a vendor specific control message for a function over USB FFS, then there is no guarantee on the timeline which the DATA/STATUS stage is responded to. While this occurs, any attempt to end transfers on non-control EPs will end up having the DWC3_EP_DELAY_STOP flag set, and defer issuing of the end transfer command. If the USB FFS application decides to timeout the control transfer, or if USB FFS AIO path exits, the USB FFS driver will issue a call to usb_ep_dequeue() for the ep0 request. In case of the AIO exit path, the AIO FS blocks until all pending USB requests utilizing the AIO path is completed. However, since the dequeue of ep0 req does not happen properly, all non-control EPs with the DWC3_EP_DELAY_STOP flag set will not be handled, and the AIO exit path will be stuck waiting for the USB FFS data endpoints to receive a completion callback. Fix is to utilize dwc3_ep0_reset_state() in the dequeue API to ensure EP0 is brought back to the SETUP state, and ensures that any deferred end transfer commands are handled. This also will end any active transfers on EP0, compared to the previous implementation which directly called giveback only. Fixes: fcd2def66392 ("usb: dwc3: gadget: Refactor dwc3_gadget_ep_dequeue") Cc: stable <stable@kernel.org> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20231206201814.32664-1-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: yurex: Fix inconsistent locking bug in yurex_read()Harshit Mogalapalli2024-01-021-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Unlock before returning on the error path. Fixes: 86b20af11e84 ("usb: yurex: Replace snprintf() with the safer scnprintf() variant") Reported-by: Dan Carpenter <error27@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202312170252.3udgrIcP-lkp@intel.com/ Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Link: https://lore.kernel.org/r/20231219063639.450994-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: typec: tipd: add patch update support for tps6598xJavier Carrasco2024-01-022-1/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TPS6598x PD controller supports firmware updates that can be loaded either from an external flash memory or a host using the device's I2C host interface. This patch implements the second approach, which is especially relevant if no flash memory is available. In order to make patch bundle updates, a series of tasks (special commands) must be sent to the device as it is documented in the TPS65987DDH and TPS65988DH Host Interface Technical Reference Manual[1], section 4.11 (Patch Bundle Update Tasks). The update sequence is as follows: 1. PTCs - Start Patch Load Sequence: the proposed approach includes device and application configuration data. 2. PTCd - Patch Download: 64-byte data chunks must be sent until the end of the firmware file is reached (the last chunk may be shorter). 3. PTCc - Patch Data Transfer Complete: ends the patch loading sequence. After this sequence and if no errors occurred, the device will change its mode to 'APP' after SETUP_MS milliseconds, and then it will be ready for normal operation. [1] https://www.ti.com/lit/ug/slvubh2b/slvubh2b.pdf?ts=1697623299919&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTPS65987D Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231207-tps6598x_update-v2-4-f3cfcde6d890@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: typec: tipd: declare in_data in as const in exec_cmd functionsJavier Carrasco2024-01-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The input data passed to execute commands with tps6598x_exec_cmd() is not supposed to be modified by the function. Moreover, this data is passed to tps6598x_exec_cmd_tmo() and finally to tps6598x_block_write(), which expects a const pointer. The current implementation does not produce any bugs, but it discards const qualifiers from the pointers passed as arguments. This leads to compile issues if 'discarded-qualifiers' is active and a const pointer is passed to the function, which is the case if data from a firmware structure is passed to execute update commands. Adding the const modifier to in_data prevents such issues and provides code consistency. Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231207-tps6598x_update-v2-3-f3cfcde6d890@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: typec: tipd: add function to request firmwareJavier Carrasco2024-01-021-9/+26
| | | | | | | | | | | | | | | | | | | | The firmware request process is device agnostic and can be used for other parts. Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231207-tps6598x_update-v2-2-f3cfcde6d890@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: typec: tipd: add init and reset functions to tipd_dataJavier Carrasco2024-01-021-10/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation includes a number of special cases for the tps25750. Nevertheless, init and reset functions can be generalized by adding function pointers to the tipd_data structure in order to offer that functionality to other parts without additional conditional clauses. Some functionality like the cold reset request (GAID) is shared by the tps25750 and the tps6598x, so they can use the same reset function. Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231207-tps6598x_update-v2-1-f3cfcde6d890@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drivers/usb/gadget/udc: Fix spelling typo in comments(reqest->request)liyouhong2024-01-022-2/+2
| | | | | | | | | | | | | | | | | | | | Fix spelling typo in comments. Reported-by: k2ci <kernel-bot@kylinos.cn> Signed-off-by: liyouhong <liyouhong@kylinos.cn> Link: https://lore.kernel.org/r/20231221023425.1316397-1-liyouhong@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Revert "usb: dwc3: don't reset device side if dwc3 was configured as host-only"Thinh Nguyen2024-01-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit e835c0a4e23c38531dcee5ef77e8d1cf462658c7. Don't omit soft-reset. During initialization, the driver may need to perform a soft reset to ensure the phy is ready when the controller updates the GCTL.PRTCAPDIR or other settings by issuing phy soft-reset. Many platforms often have access to DCTL register for soft-reset despite being host-only. If there are actual reported issues from the platforms that don't expose DCTL registers, then we will need to revisit (perhaps to teach dwc3 to perform xhci's soft-reset USBCMD.HCRST). Cc: <stable@vger.kernel.org> Fixes: e835c0a4e23c ("usb: dwc3: don't reset device side if dwc3 was configured as host-only") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/7668ab11a48f260820825274976eb41fec7f54d1.1703282469.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Revert "usb: dwc3: Soft reset phy on probe for host"Thinh Nguyen2024-01-021-38/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 8bea147dfdf823eaa8d3baeccc7aeb041b41944b. The phy soft reset GUSB2PHYCFG.PHYSOFTRST only applies to UTMI phy, not ULPI. This fix is incomplete. Cc: <stable@vger.kernel.org> Fixes: 8bea147dfdf8 ("usb: dwc3: Soft reset phy on probe for host") Reported-by: Köry Maincent <kory.maincent@bootlin.com> Closes: https://lore.kernel.org/linux-usb/20231205151959.5236c231@kmaincent-XPS-13-7390 Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/29a26593a60eba727de872a3e580a674807b3339.1703282469.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: dwc2: Disable clock gating feature on Rockchip SoCsWilliam Wu2024-01-021-0/+1
| | | | | | | | | | | | | | | | | | | | The DWC2 IP on the Rockchip SoCs doesn't support clock gating. When a clock gating is enabled, system hangs. Signed-off-by: William Wu <william.wu@rock-chips.com> Acked-by: Minas Harutyunyan <hminas@synopsys.com> Link: https://lore.kernel.org/r/1703575199-23638-1-git-send-email-william.wu@rock-chips.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Revert "usb: typec: class: fix typec_altmode_put_partner to put plugs"Heikki Krogerus2024-01-021-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit b17b7fe6dd5c6ff74b38b0758ca799cdbb79e26e. That commit messed up the reference counting, so it needs to be rethought. Fixes: b17b7fe6dd5c ("usb: typec: class: fix typec_altmode_put_partner to put plugs") Cc: <stable@vger.kernel.org> Cc: RD Babiera <rdbabiera@google.com> Reported-by: Chris Bainbridge <chris.bainbridge@gmail.com> Closes: https://lore.kernel.org/lkml/CAP-bSRb3SXpgo_BEdqZB-p1K5625fMegRZ17ZkPE1J8ZYgEHDg@mail.gmail.com/ Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240102091142.2136472-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: typec: tcpm: Parse Accessory Mode informationDmitry Baryshkov2023-12-151-0/+9
| | | | | | | | | | | | | | | | | | | | | | Some of the boards supported by the TCPM drivers can support USB-C Accessory Modes (Analog Audio, Debug). Parse information about supported modes from the device tree. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20231215173005.313422-3-dmitry.baryshkov@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * xhci: Fix null pointer dereference during S4 resume when resetting ep0Mathias Nyman2023-12-151-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During device enumeration usb core resets endpoint 0 if the max packet size value differs from the one read from the device descriptor. usb core will additionally reset endpoint 0 during S4 resume, before re-enumerating the device, if the device has a reset-resume flag set. In this case the xhci device representation vdev may be lost due to xHC restore error and re-initialization during S4 resume. Make sure slot_id and vdev are valid before trying to re-configure max packet size during endpoint 0 reset. max packet size will be re-configured later during re-enumeration. This fixes commit e34900f46cd6 ("xhci: Reconfigure endpoint 0 max packet size only during endpoint reset") which is currently in usb-next, on its way to 6.8 Fixes: e34900f46cd6 ("xhci: Reconfigure endpoint 0 max packet size only during endpoint reset") Tested-by: Wendy Wang <wendy.wang@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231215125707.1732989-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: dwc3: imx8mp: Fix smatch warningHimanshu Bhavani2023-12-151-1/+3
| | | | | | | | | | | | | | | | | | | | dwc3_imx8mp_pm_resume() warn: 'dwc3_imx->suspend_clk' from clk_prepare_enable() not released Signed-off-by: Himanshu Bhavani <himanshu.bhavani@siliconsignals.io> Link: https://lore.kernel.org/r/20231215143458.158810-1-himanshu.bhavani@siliconsignals.io Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: gadget: webcam: Make g_webcam loadable againAndrzej Pietrasiewicz2023-12-153-100/+284
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 588b9e85609b ("usb: gadget: uvc: add v4l2 enumeration api calls") has rendered the precomposed (aka legacy) webcam gadget unloadable. uvc_alloc() since then has depended on certain config groups being available in configfs tree related to the UVC function. However, legacy gadgets do not create anything in configfs, so uvc_alloc() must fail with -ENOENT no matter what. This patch mimics the required configfs hierarchy to satisfy the code which inspects formats and frames found in uvcg_streaming_header. This has been tested with guvcview on the host side, using vivid as a source of video stream on the device side and using the userspace program found at https://gitlab.freedesktop.org/camera/uvc-gadget.git. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Fixes: 588b9e85609b ("usb: gadget: uvc: add v4l2 enumeration api calls") Link: https://lore.kernel.org/r/20231215131614.29132-1-andrzej.p@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: typec: fixed a typoGhanshyam Agrawal2023-12-151-1/+1
| | | | | | | | | | | | | | | | Fixed one typo. Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com> Link: https://lore.kernel.org/r/20231215083930.566164-1-ghanshyam1898@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: cdns3: Use dev_err_probeAlexander Stein2023-12-151-5/+11
| | | | | | | | | | | | | | | | Create an error message or upon deferral add a description for sysfs. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20231214144011.1987586-1-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: gadget: f_fs: fix fortify warningDmitry Antipov2023-12-151-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling with gcc version 14.0.0 20231206 (experimental) and CONFIG_FORTIFY_SOURCE=y, I've noticed the following warning: ... In function 'fortify_memcpy_chk', inlined from '__ffs_func_bind_do_os_desc' at drivers/usb/gadget/function/f_fs.c:2934:3: ./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field' declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 588 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This call to 'memcpy()' is interpreted as an attempt to copy both 'CompatibleID' and 'SubCompatibleID' of 'struct usb_ext_compat_desc' from an address of the first one, which causes an overread warning. Since we actually want to copy both of them at once, use the convenient 'struct_group()' and 'sizeof_field()' here. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Link: https://lore.kernel.org/r/20231214090428.27292-1-dmantipov@yandex.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: storage: Remove snprintf() from sysfs call-backs and replace with ↵Lee Jones2023-12-151-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sysfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Alan Stern <stern@rowland.harvard.edu> Cc: <usb-storage@lists.one-eyed-alien.net> Signed-off-by: Lee Jones <lee@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231213164246.1021885-13-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: phy: twl6030: Remove snprintf() from sysfs call-backs and replace with ↵Lee Jones2023-12-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sysfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Hema HK <hemahk@ti.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-12-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: mon_text: Replace snprintf() with the safer scnprintf() variantLee Jones2023-12-151-23/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-11-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: mon_stat: Replace snprintf() with the safer scnprintf() variantLee Jones2023-12-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-10-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: yurex: Replace snprintf() with the safer scnprintf() variantLee Jones2023-12-151-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: host: max3421-hcd: Replace snprintf() with the safer scnprintf() variantLee Jones2023-12-151-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Cristian Birsan <cristian.birsan@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev> Cc: <linux-arm-kernel@lists.infradead.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-8-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: cdns2: Replace snprintf() with the safer scnprintf() variantLee Jones2023-12-151-69/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Pawel Laszczak <pawell@cadence.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-7-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: gadget: udc: atmel: Replace snprintf() with the safer scnprintf() variantLee Jones2023-12-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Cristian Birsan <cristian.birsan@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev> Cc: <linux-arm-kernel@lists.infradead.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-6-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: gadget: uvc: Replace snprintf() with the safer scnprintf() variantLee Jones2023-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Daniel Scally <dan.scally@ideasonboard.com> Cc: Andrzej Pietrasiewicz <andrzejtp2010@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20231213164246.1021885-5-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: gadget: f_uac2: Replace snprintf() with the safer scnprintf() variantLee Jones2023-12-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: James Gruber <jimmyjgruber@gmail.com> Cc: Yadwinder Singh <yadi.brar01@gmail.com> Cc: Jaswinder Singh <jaswinder.singh@linaro.org> Cc: Ruslan Bilovol <ruslan.bilovol@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-4-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: gadget: f_uac1: Replace snprintf() with the safer scnprintf() variantLee Jones2023-12-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Ruslan Bilovol <ruslan.bilovol@gmail.com> Cc: Julian Scheel <julian@jusst.de> Cc: Bryan Wu <cooloney@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-3-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: gadget: configfs: Replace snprintf() with the safer scnprintf() variantLee Jones2023-12-151-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-2-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: f_uac1: adds support for SS and SSPPerr Zhang2023-12-151-2/+75
| | | | | | | | | | | | | | | | | | Patch adds support of SS and SSP speed. Tested with rockchip rk3399 dwc3 Signed-off-by: Perr Zhang <perr@usb7.net> Link: https://lore.kernel.org/r/20231213112106.605260-1-strongbox8@zoho.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: typec: mux: add Qualcomm WCD939X USB SubSystem Altmode Mux driverNeil Armstrong2023-12-153-0/+790
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Qualcomm WCD9390/WCD9395 is a standalone Hi-Fi audio codec IC with a functionally separate USB SubSystem for Altmode/Analog Audio Switch accessible over an I2C interface. It provides switching USB-C USB2.0 lines between USB and Audio Headphones speaker lines, and the USB-C SBU lines between DisplayPort AUX and Audio Headphones Microphone/Ground. The Audio Headphone and Microphone data path between the Codec and the USB-C Mux subsystems are external to the IC, thus requiring DT port-endpoint graph description to handle USB-C altmode & orientation switching for Audio Accessory Mode. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231212-topic-sm8650-upstream-wcd939x-usbss-v2-2-38961fea5867@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: core: Fix crash w/ usb_choose_configuration() if no driverDouglas Anderson2023-12-151-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's possible that usb_choose_configuration() can get called when a USB device has no driver. In this case the recent commit a87b8e3be926 ("usb: core: Allow subclassed USB drivers to override usb_choose_configuration()") can cause a crash since it dereferenced the driver structure without checking for NULL. Let's add a check. A USB device with no driver is an anomaly, so make usb_choose_configuration() return immediately if there is no driver. This was seen in the real world when usbguard got ahold of a r8152 device at the wrong time. It can also be simulated via this on a computer with one r8152-based USB Ethernet adapter: cd /sys/bus/usb/drivers/r8152-cfgselector to_unbind="$(ls -d *-*)" real_dir="$(readlink -f "${to_unbind}")" echo "${to_unbind}" > unbind cd "${real_dir}" echo 0 > authorized echo 1 > authorized Fixes: a87b8e3be926 ("usb: core: Allow subclassed USB drivers to override usb_choose_configuration()") Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20231211073237.v3.1.If27eb3bf7812f91ab83810f232292f032f4203e0@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: typec: tcpm: Query Source partner for FRS capability only if it is DRPKyle Tso2023-12-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Source-only port partner will always respond NOT_SUPPORTED to GET_SINK_CAP. Avoid this redundant AMS by bailing out querying the FRS capability if the Source port partner is not DRP. Signed-off-by: Kyle Tso <kyletso@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20231205074747.1821297-1-kyletso@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: typec: change altmode SVID to u16 entryDmitry Baryshkov2023-12-151-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | As stated in the changelog for the commit 7b458a4c5d73 ("usb: typec: Add typec_port_register_altmodes()"), the code should be adjusted according to the AltMode bindings. As the SVID is 16 bits wide (according to the USB PD Spec), use fwnode_property_read_u16() to read it. Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20231204020303.2287338-3-dmitry.baryshkov@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: typec: Remove usage of the deprecated ida_simple_xx() APIChristophe JAILLET2023-12-152-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). This is less verbose. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/c7b99c4f52649ce6405779fbf9170edc5633fdbb.1702229697.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: chipidea: Remove usage of the deprecated ida_simple_xx() APIChristophe JAILLET2023-12-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). This is less verbose. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/8bf382976c0ba0986c0dbe93427266273f0776ef.1702230217.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: cdc-acm: return correct error code on unsupported breakOliver Neukum2023-12-151-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In ACM support for sending breaks to devices is optional. If a device says that it doenot support sending breaks, the host must respect that. Given the number of optional features providing tty operations for each combination is not practical and errors need to be returned dynamically if unsupported features are requested. In case a device does not support break, we want the tty layer to treat that like it treats drivers that statically cannot support sending a break. It ignores the inability and does nothing. This patch uses EOPNOTSUPP to indicate that. Signed-off-by: Oliver Neukum <oneukum@suse.com> Fixes: 9e98966c7bb94 ("tty: rework break handling") Link: https://lore.kernel.org/r/20231207132639.18250-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: dwc3: xilinx: improve error handling for PM APIsPiyush Mehta2023-12-151-4/+7
| | | | | | | | | | | | | | | | | | | | | | Improve error handling for PM APIs in the dwc3_xlnx_probe function by introducing devm_pm_runtime_enable and error label. Removed unnecessary API pm_runtime_disable call in dwc3_xlnx_remove. Signed-off-by: Piyush Mehta <piyush.mehta@amd.com> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://lore.kernel.org/r/1700590878-124335-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: fotg210-udc: fix function kernel-doc commentsRandy Dunlap2023-12-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Correct kernel-doc comments to prevent warnings from scripts/kernel-doc. fotg210-udc.c:1103: warning: Function parameter or member 'g' not described in 'fotg210_vbus_session' fotg210-udc.c:1103: warning: Excess function parameter '_gadget' description in 'fotg210_vbus_session' fotg210-udc.c:1103: warning: No description found for return value of 'fotg210_vbus_session' fotg210-udc.c:1129: warning: No description found for return value of 'fotg210_phy_event' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <linux-usb@vger.kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231206181335.27540-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: cdns3: starfive: don't misuse /** commentRandy Dunlap2023-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use a common C comment "/*" instead of "/**" to prevent a warning from scripts/kernel-doc. cdns3-starfive.c:23: warning: expecting prototype for cdns3(). Prototype was for USB_STRAP_HOST() instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Minda Chen <minda.chen@starfivetech.com> Cc: Peter Chen <peter.chen@kernel.org> Cc: Pawel Laszczak <pawell@cadence.com> Cc: Roger Quadros <rogerq@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <linux-usb@vger.kernel.org> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20231206181317.27515-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Merge 6.7-rc5 into usb-nextGreg Kroah-Hartman2023-12-114-9/+9
| |\ | | | | | | | | | | | | | | | We need the USB fixes in here as well to build off of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | usb: xhci: xhci-plat: Add support for BCM2711Stefan Wahren2023-12-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the introduction of a BCM2711 specific compatible, this also needs to be added to the xHCI driver. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20231205200531.8232-3-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | usb: hub: Add quirk to decrease IN-ep poll interval for Microchip USB491x hubHardik Gajjar2023-12-061-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a potential delay in notifying Linux USB drivers of downstream USB bus activity when connecting a high-speed or superSpeed device via the Microchip USB491x hub. This delay is due to the fixed bInterval value of 12 in the silicon of the Microchip USB491x hub. Microchip requested to ignore the device descriptor and decrease that value to 9 as it was too late to modify that in silicon. This patch speeds up the USB enummeration process that helps to pass Apple Carplay certifications and improve the User experience when utilizing the USB device via Microchip Multihost USB491x Hub. A new hub quirk HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL speeds up the notification process for Microchip USB491x hub by limiting the maximum bInterval value to 9. Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231205181829.127353-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | usb: hub: Replace hardcoded quirk value with BIT() macroHardik Gajjar2023-12-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces the hardcoded quirk value in the macro with BIT(). Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231205181829.127353-1-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | usb: typec: tcpci: add vconn over current fault handling to maxim_coreRD Babiera2023-12-041-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add TCPC_FAULT_STATUS_VCONN_OC constant and corresponding mask definition. Maxim TCPC is capable of detecting VConn over current faults, so add fault to alert mask. When a Vconn over current fault is triggered, put the port in an error recovery state via tcpm_port_error_recovery. Signed-off-by: RD Babiera <rdbabiera@google.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231121203845.170234-6-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | usb: typec: tcpm: add tcpm_port_error_recovery symbolRD Babiera2023-12-041-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add tcpm_port_error_recovery symbol and corresponding event that runs in tcpm_pd_event handler to set the port to the ERROR_RECOVERY state. tcpci drivers can use the symbol to reset the port when tcpc faults affect port functionality. Signed-off-by: RD Babiera <rdbabiera@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20231121203845.170234-5-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | usb: typec: tps6598x: add reset gpio supportJavier Carrasco2023-12-041-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TPS6598x PD controller provides an active-high hardware reset input that reinitializes all device settings. If it is not grounded by design, the driver must be able to de-assert it in order to initialize the device. The PD controller is not ready for registration right after the reset de-assertion and a delay must be introduced in that case. According to TI, the delay can reach up to 1000 ms [1], which is in line with the experimental results obtained with a TPS65987D. Add a GPIO descriptor for the reset signal and basic reset management for initialization and suspend/resume. [1] https://e2e.ti.com/support/power-management-group/power-management/ f/power-management-forum/1269856/tps65987d-tps65987d-reset-de-assert- to-normal-operation/4809389#4809389 Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230912-topic-tps6598x_reset-v3-1-0c2873070a77@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-08 13:16:53 +0000