summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-04-11usb: Remove orphaned UDC driversRob Herring (Arm)
These drivers have no way to probe as there are no match tables nor devices created with a matching name in the kernel tree. Marvell UDC was only ever supported by board files which were removed in 2022. For Marvell U3D, which was added in 2012, the PXA2128 aka MMP3 support was never upstreamed with board files and only revived in 2019 with DT support. No U3D DT support has been added since then. The PLX net2272 driver was formerly used on blackfin. It also has PCI support, but that appears to be only for a development board which is likely unused given this device dates back to 2006. Cc: Lubomir Rintel <lkundrak@v3.sk> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250407191756.3584261-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: common: usb-conn-gpio: use a unique name for usb connector deviceChance Yang
The current implementation of the usb-conn-gpio driver uses a fixed "usb-charger" name for all USB connector devices. This causes conflicts in the power supply subsystem when multiple USB connectors are present, as duplicate names are not allowed. Use IDA to manage unique IDs for naming usb connectors (e.g., usb-charger-0, usb-charger-1). Signed-off-by: Chance Yang <chance.yang@kneron.us> Link: https://lore.kernel.org/r/20250411-work-next-v3-1-7cd9aa80190c@kneron.us Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: renesas_usbhs: Reorder clock handling and power management in probeLad Prabhakar
Reorder the initialization sequence in `usbhs_probe()` to enable runtime PM before accessing registers, preventing potential crashes due to uninitialized clocks. Currently, in the probe path, registers are accessed before enabling the clocks, leading to a synchronous external abort on the RZ/V2H SoC. The problematic call flow is as follows: usbhs_probe() usbhs_sys_clock_ctrl() usbhs_bset() usbhs_write() iowrite16() <-- Register access before enabling clocks Since `iowrite16()` is performed without ensuring the required clocks are enabled, this can lead to access errors. To fix this, enable PM runtime early in the probe function and ensure clocks are acquired before register access, preventing crashes like the following on RZ/V2H: [13.272640] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP [13.280814] Modules linked in: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6 [13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98 [13.296640] Hardware name: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT) [13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs] [13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs] [13.321138] sp : ffff8000827e3850 [13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0 [13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025 [13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010 [13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff [13.352895] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000827e36ce [13.360009] x14: 00000000000003d7 x13: 00000000000003d7 x12: 0000000000000000 [13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9 : ffff8000827e3750 [13.374235] x8 : ffff0000c1850b00 x7 : 0000000003826060 x6 : 000000000000001c [13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000 [13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080 [13.395574] Call trace: [13.398013] usbhs_bset+0x14/0x4c [renesas_usbhs] (P) [13.403076] platform_probe+0x68/0xdc [13.406738] really_probe+0xbc/0x2c0 [13.410306] __driver_probe_device+0x78/0x120 [13.414653] driver_probe_device+0x3c/0x154 [13.418825] __driver_attach+0x90/0x1a0 [13.422647] bus_for_each_dev+0x7c/0xe0 [13.426470] driver_attach+0x24/0x30 [13.430032] bus_add_driver+0xe4/0x208 [13.433766] driver_register+0x68/0x130 [13.437587] __platform_driver_register+0x24/0x30 [13.442273] renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs] [13.448450] do_one_initcall+0x60/0x1d4 [13.452276] do_init_module+0x54/0x1f8 [13.456014] load_module+0x1754/0x1c98 [13.459750] init_module_from_file+0x88/0xcc [13.464004] __arm64_sys_finit_module+0x1c4/0x328 [13.468689] invoke_syscall+0x48/0x104 [13.472426] el0_svc_common.constprop.0+0xc0/0xe0 [13.477113] do_el0_svc+0x1c/0x28 [13.480415] el0_svc+0x30/0xcc [13.483460] el0t_64_sync_handler+0x10c/0x138 [13.487800] el0t_64_sync+0x198/0x19c [13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084) [13.497522] ---[ end trace 0000000000000000 ]--- Fixes: f1407d5c66240 ("usb: renesas_usbhs: Add Renesas USBHS common code") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20250407105002.107181-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: renesas_usbhs: Fix typo in commentLad Prabhakar
Fix a typo in the comment by correcting "deviece" to "device" for clarity and readability. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20250407105002.107181-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: renesas_usbhs: Correct function references in commentLad Prabhakar
Update the comment to reference `usbhs_mod_probe()` instead of `usbhs_mod_init()`, and replace `dev_set_drvdata()` with `platform_set_drvdata()`, as these are the correct functions used in this context. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20250407105002.107181-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: hub: Fail fast in USB3 link power management enable pathMathias Nyman
Enabling LPM is done in hub workqueue, often in paths handling possible link issues. So fail immediately on USB3 LPM issues and avoid hub wq from unnecessary blocking, thus allowing it to handle other port events faster. Detect errors when enabling U1/U2 link states, and return immediately if there is an issue. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250314142000.93090-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: hub: reorder USB3 link power management enable requestsMathias Nyman
Several usb requests are needed to allow a USB3 link to enter U1/U2 hardware link power management LPM states. Reorder these requests and send the more significant and likely to succeed first. This is similar to the change done for disabling LPM Enable LPM by first sending requests to the upstream hub of the device SetPortFeature(U1_TIMEOUT) SetPortFeature(U2_TIMEOUT) These are more likely to succeed due to the shorter path, and LPM can be considered enabled as link may go to U1/U2 LPM states after those. Send the requests to the device after this, they allow the device to initialte U1/U2 link transitions. Hub can already initiate U1/U2 SetFeature(U1_ENABLE) SetFeature(U2_ENABLE) Fail fast and bail out if a requests to the device fails. This changes device initated LPM policy a bit. Device is no longer able to initiate U2 if it failed or is not allowed to initiate U1. Enabling and disabling Link power management is done as part of hub work. Avoid trying to send additional USB requests to a device when there are known issues. It just causes hub work to block for even longer. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250314142000.93090-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: hub: Don't disable LPM completely if device initiated LPM failsMathias Nyman
Enabling device initiated USB3 link power management (LPM) may fail for various reasons such as too long system exit latency, or link issues. These are not good reason to disable hub initiated LPM U1/U2 states, especially as it requires sending more requests over a possibly broken link, causing the hub work to block for even longer. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250314142000.93090-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: hub: verify device is configured in usb_device_may_initiate_lpm()Mathias Nyman
Move device configured check into usb_device_may_initiate_lpm() instead of calling it before the function. No functional changes, helps rework to fail faster during link power management (LPM) enabling. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250314142000.93090-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: hub: Block less in USB3 link power management LPM disable pathMathias Nyman
Several usb requests are needed to allow or forbid a USB3 link from going into U1 or U2 hardware link power management (LPM) states. Fail fast on issues in LPM disabling path. LPM disabling is done in hub workqueue paths that are often already handling possible link issues. Enabling and disabling LPM involves four usb requests. Two requests sent to the upstream hub of the connected device: SetPortFeature(U1_TIMEOUT) SetPortFeature(U2_TIMEOUT) And two to the device itself: SetFeature(U1_ENABLE) SetFeature(U2_ENABLE) The requests to the hub sets the inactivity timeout used by the hub to know when to initiate U1 and U2 LPM link state transitions. These requests are also used prevent U1/U2 LPM transitions completely by passing zero timeout value. The requsts sent to the device only controls if device is allowed to initiate U1/U2 transitions. If not enabled then only hub initiates U1/U2 transitions. Hub may block these device initiated attempts. Reorder and send the hub requests first, these are more likely to succeed due to shorter path, and we can consider LPM disabled if these succeed as U1/U2 link state can not be entered after that. Fail immediately if a request fails, and don't try to enable back LPM after a failed request, that will just send more LPM requests over a bad link. If a device request controlling device initiateed LPM fails then exit immediately, but consider LPM disabled at this stage. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250314142000.93090-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: Add checks for snprintf() calls in usb_alloc_dev()Andy Shevchenko
When creating a device path in the driver the snprintf() takes up to 16 characters long argument along with the additional up to 12 characters for the signed integer (as it can't see the actual limits) and tries to pack this into 16 bytes array. GCC complains about that when build with `make W=1`: drivers/usb/core/usb.c:705:25: note: ‘snprintf’ output between 3 and 28 bytes into a destination of size 16 Since everything works until now, let's just check for the potential buffer overflow and bail out. It is most likely a never happen situation, but at least it makes GCC happy. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250321164949.423957-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: chipidea: imx: add HSIO Block Control wakeup settingXu Yang
On i.MX95 platform, USB wakeup setting is controlled by HSIO Block Control: HSIO Block Control Overview: - The HSIO block control include configuration and status registers that provide miscellaneous top-level controls for clocking, beat limiter enables, wakeup signal enables and interrupt status for the PCIe and USB interfaces. The wakeup function of HSIO blkctl is basically same as non-core, except improvements about power lost cases. This will add the wakeup setting for HSIO blkctl on i.MX95. It will firstly ioremap hsio blkctl memory, then do wakeup setting as needs. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Jun Li <jun.li@nxp.com> Acked-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20250318150908.1583652-4-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: chipidea: imx: add wakeup interrupt handlingXu Yang
In previous imx platform, normal USB controller interrupt and wakeup interrupt are bound to one irq line. However, it changes on latest i.MX95 platform since it has a dedicated irq line for wakeup interrupt. This will add wakeup interrupt handling for i.MX95 to support various wakeup events. Acked-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20250318150908.1583652-3-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11dt-bindings: usb: usbmisc-imx: add support for i.MX95 platformXu Yang
Add compatible string "fsl,imx95-usbmisc" for i.MX95 platform and restriction on reg property. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20250318150908.1583652-2-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11dt-bindings: usb: chipidea: Add i.MX95 compatible string 'fsl,imx95-usb'Xu Yang
The i.MX95 USB2.0 controller is mostly compatible with i.MX7D, except it requires a second interrupt for wakeup handling. Add the compatible string for the i.MX95 platform, add the iommus property, and enforce the interrupt property restriction. Keep the same restriction for existing compatible strings. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20250318150908.1583652-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: ehci-fsl: Fix use of private data to avoid ↵Alan Stern
-Wflex-array-member-not-at-end warning In the course of fixing up the usages of flexible arrays, Gustavo submitted a patch updating the ehci-fsl driver. However, the patch was wrong because the driver was using the .priv member of the ehci_hcd structure incorrectly. The private data is not supposed to be a wrapper containing the ehci_hcd structure; it is supposed to be a sub-structure stored in the .priv member. Fix the problem by replacing the ehci_fsl structure with ehci_fsl_priv, containing only the private data, along with a suitable conversion macro for accessing it. This removes the problem of having data follow a flexible array member. Reported-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/linux-usb/Z-R9BcnSzrRv5FX_@kspp/ Reviewed-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/8139e4cc-4e5c-40e2-9c4b-717ad3215868@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: cdc-wdm: avoid setting WDM_READ for ZLP-sRobert Hodaszi
Don't set WDM_READ flag in wdm_in_callback() for ZLP-s, otherwise when userspace tries to poll for available data, it might - incorrectly - believe there is something available, and when it tries to non-blocking read it, it might get stuck in the read loop. For example this is what glib does for non-blocking read (briefly): 1. poll() 2. if poll returns with non-zero, starts a read data loop: a. loop on poll() (EINTR disabled) b. if revents was set, reads data I. if read returns with EINTR or EAGAIN, goto 2.a. II. otherwise return with data So if ZLP sets WDM_READ (#1), we expect data, and try to read it (#2). But as that was a ZLP, and we are doing non-blocking read, wdm_read() returns with EAGAIN (#2.b.I), so loop again, and try to read again (#2.a.). With glib, we might stuck in this loop forever, as EINTR is disabled (#2.a). Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com> Acked-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20250403144004.3889125-1-robert.hodaszi@digi.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11dt-bindings: usb: smsc,usb3503: Correct indentation and style in DTS exampleKrzysztof Kozlowski
DTS example in the bindings should be indented with 2- or 4-spaces and aligned with opening '- |', so correct any differences like 3-spaces or mixtures 2- and 4-spaces in one binding. No functional changes here, but saves some comments during reviews of new patches built on existing code. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250324125142.81910-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: gadget: udc-xilinx: Remove the invalid commentLi Qiong
The function don't return value, remove the invalid comment. Signed-off-by: Li Qiong <liqiong@nfschina.com> Link: https://lore.kernel.org/r/20250314101639.424013-2-liqiong@nfschina.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: cdns3: Remove the invalid commentLi Qiong
The function don't return value, remove the invalid comment. Signed-off-by: Li Qiong <liqiong@nfschina.com> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20250314101639.424013-1-liqiong@nfschina.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: gadget: f_hid: wake up readers on disable/unbindPeter Korsgaard
Similar to how it is done in the write path. Add a disabled flag to track the function state and use it to exit the read loops to ensure no readers get stuck when the function is disabled/unbound, protecting against corruption when the waitq and spinlocks are reinitialized in hidg_bind(). Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Link: https://lore.kernel.org/r/20250318152207.330997-1-peter@korsgaard.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: gadget: uvc: Avoid -Wflex-array-member-not-at-end warningsGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Move the conflicting declaration to the end of the structure. Notice that `struct uvc_input_header_descriptor` is a flexible structure --a structure that contains a flexible-array member. With this, fix three of the following warnings: drivers/usb/gadget/function/uvc_configfs.h:77:57: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/Z9dyY7_ydJiGqh_d@kspp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11USB: gadget: Replace deprecated strncpy() with strscpy()Thorsten Blum
strncpy() is deprecated for NUL-terminated destination buffers; use strscpy() instead. Since kzalloc() already zeroes out the destination buffer, the potential NUL-padding by strncpy() is unnecessary. strscpy() copies only the required characters and guarantees NUL-termination. Since the destination buffer has a fixed length, strscpy() automatically determines its size using sizeof() when the argument is omitted. This makes an explicit sizeof() call unnecessary. The source string is also NUL-terminated and meets the __must_be_cstr() requirement of strscpy(). No functional changes intended. Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/20250320165647.34859-2-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11dt-bindings: usb: dwc3: Allow connector in USB controller nodeMatthias Schiffer
Allow specifying the connector directly in the USB controller node, as allow in other USB controller bindings and commonly used for "gpio-usb-b-connector". Linux already supports this without driver changes. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250325131848.127438-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11dt-bindings: usb: qcom,dwc3: Add SM8750 compatibleWesley Cheng
SM8750 uses the Synopsys DWC3 controller. Add this to the compatibles list to utilize the DWC3 QCOM and DWC3 core framework. Other than a revision bump to DWC3 controller rev2.00a, the controller on SM8750 does not add any additional vendor specific features compared to previous chipsets. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Signed-off-by: Melody Olvera <melody.olvera@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250409-sm8750_usb_master-v4-3-6ec621c98be6@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: dwc3: core: Avoid redundant system suspend/resume callbacksRoy Luo
dwc3 device suspend/resume callbacks were being triggered during system suspend and resume even if the device was already runtime-suspended. This is redundant for device mode because the suspend and resume routines are essentially identical for system PM and runtime PM. To prevent these unnecessary callbacks, indicate to the PM core that it can safely leave the device in runtime suspend if it's already runtime-suspended in device mode by returning a positive value in prepare() callback. This optimization only applies to devices without pinctrl, as pinctrl has distinct logic tied to system suspend/resume. Signed-off-by: Roy Luo <royluo@google.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20250312223434.3071598-1-royluo@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: typec: displayport: Receive DP Status Update NAK request exit dp altmodeJos Wang
Although some Type-C DRD devices that do not support the DP Sink function (such as Huawei Mate 40Pro), the Source Port initiates Enter Mode CMD, but the device responds to Enter Mode ACK, the Source port then initiates DP Status Update CMD, and the device responds to DP Status Update NAK. As PD2.0 spec ("6.4.4.3.4 Enter Mode Command"),A DR_Swap Message Shall Not be sent during Modal Operation between the Port Partners. At this time, the source port initiates DR_Swap message through the "echo device > /sys/class/typec/port0/data_role" command to switch the data role from host to device. The device will initiate a Hard Reset for recovery, resulting in the failure of data role swap. Therefore, when DP Status Update NAK is received, Exit Mode CMD is initiated to exit the currently entered DP altmode. Signed-off-by: Jos Wang <joswang@lenovo.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250209071926.69625-1-joswang1221@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: typec: tipd: Fix wakeup source leaks on device unbindKrzysztof Kozlowski
Device can be unbound, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250406204051.63446-2-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: typec: tcpci: Fix wakeup source leaks on device unbindKrzysztof Kozlowski
Device can be unbound, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250406204051.63446-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: typec: tcpci: add regulator supportMichael Grzeschik
The tcpci chip vbus pin is possibly driven by an regulator. This patch is adding support to enable an optional vdd regulator before probing. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250404-ml-topic-tcpci-v1-1-4442c7d0ee1e@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: typec: tcpm: allow switching to mode accessory to mux properlyMichael Grzeschik
The funciton tcpm_acc_attach is not setting the proper state when calling tcpm_set_role. The function tcpm_set_role is currently only handling TYPEC_STATE_USB. For the tcpm_acc_attach to switch into other modal states tcpm_set_role needs to be extended by an extra state parameter. This patch is handling the proper state change when calling tcpm_acc_attach. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250404-ml-topic-tcpm-v1-3-b99f44badce8@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: typec: tcpm: allow sink (ufp) to toggle into accessory mode debugMichael Grzeschik
This patch extends the is_debug macro to cover the sink case (ufp). It also handles the transition to access the DEBUG_ACC_ATTACHED state in the sink case. It also handles the debounce case in which the cc pins are not immediately valid after the plug event. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250404-ml-topic-tcpm-v1-2-b99f44badce8@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: typec: tcpm: allow to use sink in accessory modeMichael Grzeschik
Since the function tcpm_acc_attach is not setting the data and role for for the sink case we extend it to check for it first. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250404-ml-topic-tcpm-v1-1-b99f44badce8@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: typec: mux: do not return on EOPNOTSUPP in {mux, switch}_setMichael Grzeschik
Since the typec connectors can have many muxes or switches for different lanes (sbu, usb2, usb3) going into different modal states (usb2, usb3, audio, debug) all of them will be called on typec_switch_set and typec_mux_set. But not all of them will be handling the expected mode. If one of the mux or switch will come back with EOPTNOSUPP this is no reason to stop running through the next ones. Therefor we skip this particular error value and continue calling the next. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250404-ml-topic-typec-mux-v1-1-22c0526381ba@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: typec: ucsi: Add the UCSI commands in debugfsMadhu M
Added the UCSI commands UCSI_GET_CAM_SUPPORTED, UCSI_GET_PD_MESSAGE, UCSI_GET_ATTENTION_VDO and UCSI_SET_USB support in debugfs to enhance PD/TypeC debugging capability Signed-off-by: Madhu M <madhu.m@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250402070817.1016635-1-madhu.m@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11usb: typec: ucsi: add Huawei Matebook E Go ucsi driverPengyu Luo
The Huawei Matebook E Go tablet implements the UCSI interface in the onboard EC. Add the glue driver to interface with the platform's UCSI implementation. This driver is inspired by the following drivers: drivers/usb/typec/ucsi/ucsi_yoga_c630.c drivers/usb/typec/ucsi/ucsi_glink.c drivers/soc/qcom/pmic_glink_altmode.c Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250316094357.462022-1-mitltlatltl@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ALSA: usb-audio: qcom: Notify USB audio devices on USB offload probingWesley Cheng
If the vendor USB offload class driver is not ready/initialized before USB SND discovers attached devices, utilize snd_usb_rediscover_devices() to find all currently attached devices, so that the ASoC entities are notified on available USB audio devices. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-32-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ALSA: usb-audio: qcom: Add USB offload route kcontrolWesley Cheng
In order to allow userspace/applications know about USB offloading status, expose a sound kcontrol that fetches information about which sound card and PCM index the USB device is mapped to for supporting offloading. In the USB audio offloading framework, the ASoC BE DAI link is the entity responsible for registering to the SOC USB layer. It is expected for the USB SND offloading driver to add the kcontrol to the sound card associated with the USB audio device. An example output would look like: tinymix -D 1 get 'USB Offload Playback Route PCM#0' -1, -1 (range -1->255) This example signifies that there is no mapped ASoC path available for the USB SND device. tinymix -D 1 get 'USB Offload Playback Route PCM#0' 0, 0 (range -1->255) This example signifies that the offload path is available over ASoC sound card index#0 and PCM device#0. The USB offload kcontrol will be added in addition to the existing kcontrols identified by the USB SND mixer. The kcontrols used to modify the USB audio device specific parameters are still valid and expected to be used. These parameters are not mirrored to the ASoC subsystem. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-31-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ALSA: usb-audio: qcom: Don't allow USB offload path if PCM device is in useWesley Cheng
Add proper checks and updates to the USB substream once receiving a USB QMI stream enable request. If the substream is already in use from the non offload path, reject the stream enable request. In addition, update the USB substream opened parameter when enabling the offload path, so the non offload path can be blocked. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-30-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ALSA: usb-audio: qcom: Introduce QC USB SND offloading supportWesley Cheng
Several Qualcomm SoCs have a dedicated audio DSP, which has the ability to support USB sound devices. This vendor driver will implement the required handshaking with the DSP, in order to pass along required resources that will be utilized by the DSP's USB SW. The communication channel used for this handshaking will be using the QMI protocol. Required resources include: - Allocated secondary event ring address - EP transfer ring address - Interrupter number The above information will allow for the audio DSP to execute USB transfers over the USB bus. It will also be able to support devices that have an implicit feedback and sync endpoint as well. Offloading these data transfers will allow the main/applications processor to enter lower CPU power modes, and sustain a longer duration in those modes. Audio offloading is initiated with the following sequence: 1. Userspace configures to route audio playback to USB backend and starts playback on the platform soundcard. 2. The Q6DSP AFE will communicate to the audio DSP to start the USB AFE port. 3. This results in a QMI packet with a STREAM enable command. 4. The QC audio offload driver will fetch the required resources, and pass this information as part of the QMI response to the STREAM enable command. 5. Once the QMI response is received the audio DSP will start queuing data on the USB bus. As part of step#2, the audio DSP is aware of the USB SND card and pcm device index that is being selected, and is communicated as part of the QMI request received by QC audio offload. These indices will be used to handle the stream enable QMI request. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-29-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ALSA: usb-audio: qcom: Add USB QMI definitionsWesley Cheng
The Qualcomm USB audio offload driver utilizes the QMI protocol to communicate with the audio DSP. Add the necessary QMI header and field definitions, so the QMI interface driver is able to route the QMI packet received to the USB audio offload driver. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-28-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ASoC: qcom: qdsp6: Fetch USB offload mapped card and PCM deviceWesley Cheng
The USB SND path may need to know how the USB offload path is routed, so that applications can open the proper sound card and PCM device. The implementation for the QC ASoC design has a "USB Mixer" kcontrol for each possible FE (Q6ASM) DAI, which can be utilized to know which front end link is enabled. When an application/userspace queries for the mapped offload devices, the logic will lookup the USB mixer status though the following path: MultiMedia* <-> MM_DL* <-> USB Mixer* The "USB Mixer" is a DAPM widget, and the q6routing entity will set the DAPM connect status accordingly if the USB mixer is enabled. If enabled, the Q6USB backend link can fetch the PCM device number from the FE DAI link (Multimedia*). With respects to the card number, that is straightforward, as the ASoC components have direct references to the ASoC platform sound card. An example output can be shown below: Number of controls: 9 name value Capture Channel Map 0, 0 (range 0->36) Playback Channel Map 0, 0 (range 0->36) Headset Capture Switch On Headset Capture Volume 1 (range 0->4) Sidetone Playback Switch On Sidetone Playback Volume 4096 (range 0->8192) Headset Playback Switch On Headset Playback Volume 20, 20 (range 0->24) USB Offload Playback Route PCM#0 0, 1 (range -1->255) The "USB Offload Playback Route PCM#*" kcontrol will signify the corresponding card and pcm device it is offload to. (card#0 pcm - device#1) If the USB SND device supports multiple audio interfaces, then it will contain several PCM streams, hence in those situations, it is expected that there will be multiple playback route kcontrols created. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-27-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ASoC: qcom: qdsp6: Add headphone jack for offload connection statusWesley Cheng
The headphone jack framework has a well defined infrastructure for notifying userspace entities through input devices. Expose a jack device that carries information about if an offload capable device is connected. Applications can further identify specific offloading information through other SND kcontrols. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-26-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ASoC: qcom: qdsp6: Add USB backend ASoC driver for Q6Wesley Cheng
Create a USB BE component that will register a new USB port to the ASoC USB framework. This will handle determination on if the requested audio profile is supported by the USB device currently selected. Check for if the PCM format is supported during the hw_params callback. If the profile is not supported then the userspace ALSA entity will receive an error, and can take further action. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-25-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ASoC: qcom: qdsp6: q6afe: Increase APR timeoutWesley Cheng
For USB offloading situations, the AFE port start command will result in a QMI handshake between the Q6DSP and the main processor. Depending on if the USB bus is suspended, this routine would require more time to complete, as resuming the USB bus has some overhead associated with it. Increase the timeout to 3s to allow for sufficient time for the USB QMI stream enable handshake to complete. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-24-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ASoC: qcom: qdsp6: Introduce USB AFE port to q6dspWesley Cheng
The QC ADSP is able to support USB playback endpoints, so that the main application processor can be placed into lower CPU power modes. This adds the required AFE port configurations and port start command to start an audio session. Specifically, the QC ADSP can support all potential endpoints that are exposed by the audio data interface. This includes isochronous data endpoints, in either synchronous mode or asynchronous mode. In the latter case both implicit or explicit feedback endpoints are supported. The size of audio samples sent per USB frame (microframe) will be adjusted based on information received on the feedback endpoint. Some pre-requisites are needed before issuing the AFE port start command, such as setting the USB AFE dev_token. This carries information about the available USB SND cards and PCM devices that have been discovered on the USB bus. The dev_token field is used by the audio DSP to notify the USB offload driver of which card and PCM index to enable playback on. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-23-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ASoC: dt-bindings: Update example for enabling USB offload on SM8250Wesley Cheng
Add an example on enabling of USB offload for the Q6DSP. The routing can be done by the mixer, which can pass the multimedia stream to the USB backend. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-22-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ASoC: dt-bindings: qcom,q6dsp-lpass-ports: Add USB_RX portWesley Cheng
Q6DSP supports handling of USB playback audio data if USB audio offloading is enabled. Add a new definition for the USB_RX AFE port, which is referenced when the AFE port is started. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-21-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ASoC: doc: Add documentation for SOC USBWesley Cheng
With the introduction of the soc-usb driver, add documentation highlighting details on how to utilize the new driver and how it interacts with different components in USB SND and ASoC. It provides examples on how to implement the drivers that will need to be introduced in order to enable USB audio offloading. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-20-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-11ASoC: usb: Rediscover USB SND devices on USB port addWesley Cheng
In case the USB backend device has not been initialized/probed, USB SND device connections can still occur. When the USB backend is eventually made available, previous USB SND device connections are not communicated to the USB backend. Call snd_usb_rediscover_devices() to generate the connect callbacks for all USB SND devices connected. This will allow for the USB backend to be updated with the current set of devices available. The chip array entries are all populated and removed while under the register_mutex, so going over potential race conditions: Thread#1: q6usb_component_probe() --> snd_soc_usb_add_port() --> snd_usb_rediscover_devices() --> mutex_lock(register_mutex) Thread#2 --> usb_audio_disconnect() --> mutex_lock(register_mutex) So either thread#1 or thread#2 will complete first. If Thread#1 completes before thread#2: SOC USB will notify DPCM backend of the device connection. Shortly after, once thread#2 runs, we will get a disconnect event for the connected device. Thread#2 completes before thread#1: Then during snd_usb_rediscover_devices() it won't notify of any connection for that particular chip index. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250409194804.3773260-19-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>