- 04 Jan, 2024 1 commit
-
-
Wesley Cheng authored
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: fcd2def6 ("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.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 02 Jan, 2024 11 commits
-
-
Harshit Mogalapalli authored
Unlock before returning on the error path. Fixes: 86b20af1 ("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.comSigned-off-by:
-
Javier Carrasco authored
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%252FTPS65987DSigned-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.netSigned-off-by:
-
Javier Carrasco authored
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 authored
The firmware request process is device agnostic and can be used for other parts. Signed-off-by:
-
Javier Carrasco authored
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:
-
liyouhong authored
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.cnSigned-off-by:
-
Thinh Nguyen authored
This reverts commit e835c0a4. 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: e835c0a4 ("usb: dwc3: don't reset device side if dwc3 was configured as host-only") Signed-off-by:
-
Thinh Nguyen authored
This reverts commit 8bea147d. The phy soft reset GUSB2PHYCFG.PHYSOFTRST only applies to UTMI phy, not ULPI. This fix is incomplete. Cc: <stable@vger.kernel.org> Fixes: 8bea147d ("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-7390Signed-off-by:
-
William Wu authored
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.comSigned-off-by:
-
Heikki Krogerus authored
This reverts commit b17b7fe6. That commit messed up the reference counting, so it needs to be rethought. Fixes: b17b7fe6 ("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:
-
Greg Kroah-Hartman authored
Merge tag 'thunderbolt-for-v6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into char-misc-next Mika writes: thunderbolt: Changes for v6.8 merge window This includes following USB4/Thunderbolt changes for the v6.8 merge window: - Intel Lunar Lake support - PCIe tunneling improvements - DisplayPort tunneling improvements - Asymmetric switching improvements - Couple of minor fixes and cleanups. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Reduce retry timeout to speed up boot for some devices thunderbolt: Keep link as asymmetric if preferred by hardware thunderbolt: Add support for Intel Lunar Lake thunderbolt: Disable PCIe extended encapsulation upon teardown properly thunderbolt: Make PCIe tunnel setup and teardown follow CM guide thunderbolt: Improve logging when DisplayPort resource is added due to hotplug thunderbolt: Use tb_dp_read_cap() to read DP_COMMON_CAP as well thunderbolt: Disable CL states only when actually needed thunderbolt: Transition link to asymmetric only when both sides support it thunderbolt: Log XDomain link speed and width thunderbolt: Move width_name() helper to tb.h thunderbolt: Handle lane bonding of Gen 4 XDomain links properly thunderbolt: Unwind TMU configuration if tb_switch_set_tmu_mode_params() fails thunderbolt: Remove duplicated re-assignment of pointer 'out'
-
- 23 Dec, 2023 1 commit
-
-
Randy Dunlap authored
Remove the @removable: line to prevent the kernel-doc warning: include/linux/usb.h:732: warning: Excess struct member 'removable' description in 'usb_device' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Link: https://lore.kernel.org/r/20231223050636.14022-1-rdunlap@infradead.orgSigned-off-by:
-
- 22 Dec, 2023 2 commits
-
-
Werner Sembach authored
This is a followup to "thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge". It seems like the timeout can be reduced to 250ms. This reduces the overall delay caused by the retires to ~1s. This is about the time other things being initialized in parallel need anyway*, so like this the effective boot time is no longer compromised. *I only had a single device available for my measurements: A Clevo X170KM-G desktop replacement notebook. Signed-off-by:
Werner Sembach <wse@tuxedocomputers.com> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com>
-
Gil Fine authored
In case of the link is brought up as asymmetric (due to hardware preference), we honor that and don't transition it to symmetric, unless a router with symmetric link got plugged below, in the topology (and a bandwidth allows transition to symmetric). Signed-off-by:
Gil Fine <gil.fine@linux.intel.com> Signed-off-by:
-
- 20 Dec, 2023 1 commit
-
-
Greg Kroah-Hartman authored
Now that the driver core can properly handle constant struct bus_type, move the tb_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Michael Jamet <michael.jamet@intel.com> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Cc: <linux-usb@vger.kernel.org> Acked-by:
-
- 15 Dec, 2023 24 commits
-
-
Dmitry Baryshkov authored
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:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20231215173005.313422-3-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
Add description of the USB-C Accessory Modes supported on the particular USB-C connector. This is required for devices like Qualcomm SM8150-HDK, which have no other way to express accessory modes supported by the hardware platform. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Mathias Nyman authored
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 e34900f4 ("xhci: Reconfigure endpoint 0 max packet size only during endpoint reset") which is currently in usb-next, on its way to 6.8 Fixes: e34900f4 ("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.comSigned-off-by:
-
Himanshu Bhavani authored
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.ioSigned-off-by:
-
Andrzej Pietrasiewicz authored
commit 588b9e85 ("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: 588b9e85 ("usb: gadget: uvc: add v4l2 enumeration api calls") Link: https://lore.kernel.org/r/20231215131614.29132-1-andrzej.p@collabora.comSigned-off-by:
-
Abel Vesa authored
Add X1E80100 to the DT schema. Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231214-x1e80100-usb-v1-1-c22be5c0109e@linaro.orgSigned-off-by:
-
Ghanshyam Agrawal authored
Fixed one typo. Signed-off-by:
Ghanshyam Agrawal <ghanshyam1898@gmail.com> Link: https://lore.kernel.org/r/20231215083930.566164-1-ghanshyam1898@gmail.comSigned-off-by:
-
Alexander Stein authored
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.comSigned-off-by:
-
Dmitry Antipov authored
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.ruSigned-off-by:
-
Lee Jones authored
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.orgSigned-off-by:
-
Lee Jones authored
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 authored
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/105Signed-off-by: -
Lee Jones authored
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/105Signed-off-by: -
Lee Jones authored
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 authored
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 authored
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 authored
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 authored
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:Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20231213164246.1021885-5-lee@kernel.orgSigned-off-by:
-
Lee Jones authored
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 authored
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 authored
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/105Signed-off-by: -
Perr Zhang authored
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.comSigned-off-by:
-
Neil Armstrong authored
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.orgSigned-off-by:
-
Neil Armstrong authored
Document the Qualcomm WCD9390/WCD9395 USB SubSystem Altmode/Analog Audio Switch which is a separate USB SubSystem for Altmode/Analog Audio Switch accessible over an I2C interface. Since Audio Headphone and Microphone data path between the Codec and the USB-C Mux subsystems are external to the IC, it requires a second port to handle USB-C altmode & orientation switching for Audio Accessory Mode to the Codec SubSystem. Signed-off-by:
-
