summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-02-04phy: GOOGLE_USB: add TYPEC dependencyArnd Bergmann1-0/+1
With CONFIG_TYPEC=m, this driver cannot be built-in: arm-linux-gnueabi/bin/arm-linux-gnueabi-ld: drivers/phy/phy-google-usb.o: in function `google_usb_phy_remove': phy-google-usb.c:(.text+0x24): undefined reference to `typec_switch_unregister' Add CONFIG_TYPEC as a hard dependency here to force a clean build. In theory, compile-testing with CONFIG_TYPEC=n would also work, but that seems pointless. Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260202095655.1289973-1-arnd@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-02-04phy: enter drivers/phy/Makefile even without CONFIG_GENERIC_PHYVladimir Oltean2-2/+2
Kconfig option CONFIG_PHY_COMMON_PROPS, which builds drivers/phy/phy-common-props.c, was intended to be selectable independently of CONFIG_GENERIC_PHY. Yet it lives in drivers/phy/, which is entered by the Makefile only if CONFIG_GENERIC_PHY is set. Allow the Makefile to enter one level deeper, but stop at drivers/phy/ if CONFIG_GENERIC_PHY is unselected (i.e. do not enter vendor folders). The other stuff from drivers/phy/Makefile except for CONFIG_PHY_COMMON_PROPS, like CONFIG_PHY_NXP_PTN3222, all depends on CONFIG_GENERIC_PHY. Fixes: e7556b59ba65 ("phy: add phy_get_rx_polarity() and phy_get_tx_polarity()") Closes: https://lore.kernel.org/lkml/43ea0202-891d-4582-980b-5cb557b41114@linux.ibm.com/ Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Debugged-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Link: https://patch.msgid.link/20260123110600.3118561-1-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: renesas: rcar-gen3-usb2: Use mux-state for phyrst managementTommaso Merciai2-0/+33
Add support for selecting the phyrst mux-state using the Linux mux subsystem in the R-Car Gen3 USB2 PHY driver. This ensures correct hardware initialization and integration with systems utilizing the mux-state device tree property. A temporary wrapper for optional muxes is introduced until native support is available in the multiplexer subsystem. Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/80aafdb2367dcada720b0a9ebeea344764e710fb.1766405010.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS controlTommaso Merciai1-5/+137
Enable OTG VBUS control on R-Car Gen3 USB2 PHY by registering a regulator driver that manages the VBOUT line. This change allows the controller to handle VBUS output for OTG ports using the regulator framework when the platform requires hardware-based VBUS control. Without this, some platforms cannot properly manage VBUS power on OTG- capable ports, leading to potential USB functionality issues. Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/6c1aebf60b4d8ff0c51a8243c68b397c1a384867.1766405010.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: renesas: rcar-gen3-usb2: Use devm_pm_runtime_enable()Tommaso Merciai1-32/+21
Replace pm_runtime_enable() with devm_pm_runtime_enable() to ensure proper cleanup if the probe fails. This change enhances driver reliability by avoiding resource leaks, as the devm-managed version automatically handles disabling at probe failure or device removal. Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/ca028d41f84227efeccb0cbdff22fbf16e5cf6ab.1766405010.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: renesas: rcar-gen3-usb2: Factor out VBUS control logicTommaso Merciai1-12/+22
Refactor the VBUS control logic into a new helper function to improve code clarity and reduce duplication. This makes it easier to handle different VBUS control register cases and aids future maintenance. Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/2d94c9876b965bdf7cd74cdbbc0c54689e122798.1766405010.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21dt-bindings: phy: renesas,usb2-phy: Document RZ/G3E SoCTommaso Merciai1-1/+3
Document USB2.0 phy bindings for RZ/G3E ("R9A09G047") SoC. The RZ/G3E USB2.0 phy is functionally identical to the one found on the RZ/V2H(P), so no driver changes are needed. The existing "renesas,usb2-phy-r9a09g057" will be used as a fallback compatible for this IP. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/4f2454708428b48e03faabe79e383999fb1ab458.1766405010.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21dt-bindings: phy: renesas,usb2-phy: Document mux-states propertyTommaso Merciai1-0/+5
Some Renesas SoCs, such as RZ/G3E, provide a USB2.0 OTG PHY with configurable VBUS control through a multiplexed hardware register. This register allows selecting the VBUS source via a mux control line exposed by the PHY. To represent this hardware configuration, support the standard `mux-states` property in the Renesas USB2 PHY binding. This allows the DeviceTree to model the VBUS source selection as a mux, consistent with generic binding conventions. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/36d448dd10bbb2bbfa5b1b6b6e3fee86c34d01aa.1766405010.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21dt-bindings: phy: renesas,usb2-phy: Document USB VBUS regulatorTommaso Merciai1-0/+6
Document the 'vbus-regulator' child node in the Renesas USB2 PHY binding to describe the internal USB VBUS regulator. Require this regulator node on OTG channels to accurately represent hardware dependencies in the device tree. Documenting this regulator allows device trees to model the VBUS power requirements of these SoCs properly. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/aaa8044283eb736817afd43d4fba3aa93b50b1dd.1766405010.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL supportCristian Ciocaltea1-23/+418
The PHY is capable of handling four HDMI 2.1 Fixed Rate Link (FRL) lanes, and each one can operate at any of the rates of 3Gbps, 6Gbps, 8Gbps, 10Gbps or 12Gbps. Add the necessary driver changes to support the feature. Co-developed-by: Algea Cao <algea.cao@rock-chips.com> Signed-off-by: Algea Cao <algea.cao@rock-chips.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-11-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: rockchip: samsung-hdptx: Extend rk_hdptx_phy_verify_hdmi_config() helperCristian Ciocaltea1-17/+18
In order to facilitate introduction of HDMI 2.1 FRL support and to avoid recomputing the link rate after verifying the HDMI configuration given as input, extend rk_hdptx_phy_verify_hdmi_config() by providing an optional output parameter to store the validated configuration. For improved code readability, also rename the existing hdmi input parameter. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-10-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: rockchip: samsung-hdptx: Switch to driver specific HDMI configCristian Ciocaltea1-21/+26
In preparation to support the FRL operation mode which gets configured via the lanes and rate per lane tuple, switch to a driver specific struct for configuring the link rate and bpc. This simplifies and optimizes the implementation by allowing implicit switches between TMDS and FRL rates, without requiring additional checks of the active PHY mode followed by recalculations of the link rate when operating in FRL mode. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-9-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: rockchip: samsung-hdptx: Drop hw_rate driver dataCristian Ciocaltea1-11/+2
The ->hw_rate member of struct rk_hdptx_phy was mainly used to keep track of the clock rate programmed in hardware and support implementing the ->recalc_rate() callback in hdptx_phy_clk_ops. Computing the clock rate from the actual PHY PLL configuration seems to work reliably, hence remove the now redundant struct member. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-8-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: rockchip: samsung-hdptx: Compute clk rate from PLL configCristian Ciocaltea1-1/+90
Improve ->recalc_rate() callback of hdptx_phy_clk_ops to calculate the initial clock rate based on the actual PHY PLL configuration as retrieved from the related hardware registers. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-7-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: rockchip: samsung-hdptx: Cleanup *_cmn_init_seq listsCristian Ciocaltea1-18/+4
Drop redundant reg_sequence entries from rk_hdptx_common_cmn_init_seq[], i.e. those that are either duplicated or overridden in rk_hdptx_tmds_cmn_init_seq[]. Additionally, a few items do not really belong to the former, hence move them to the latter. That's mostly a preparatory step for adding FRL support. No functional changes intended at this point. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-6-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: rockchip: samsung-hdptx: Enable lane output in common helperCristian Ciocaltea1-1/+3
In preparation to support FRL mode, move the PHY lane output enablement from the TMDS specific configuration to the common *_post_enable_lane() helper and make sure it gets turned off in *_phy_disable(). Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-5-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: rockchip: samsung-hdptx: Consistently use [rk_]hdptx_[tmds_] prefixesCristian Ciocaltea1-31/+31
Fix the naming inconsistencies for some of the functions and global variables: * Add the missing 'rk_hdptx_' prefix to ropll_tmds_cfg variable * Replace '_ropll_tmds_' with '_tmds_ropll_' globally * Replace 'hdtpx' with 'hdptx' globally Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-4-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: rockchip: samsung-hdptx: Fix coding style alignmentCristian Ciocaltea1-6/+6
Handle a bunch of reported checkpatch.pl complaints: CHECK: Alignment should match open parenthesis Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-3-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: rockchip: samsung-hdptx: Use usleep_range() instead of udelay()Cristian Ciocaltea1-1/+1
rk_hdptx_dp_reset() is allowed to sleep, hence replace the busy waiting with usleep_range(), to allow other threads to run. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-2-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: hdmi: Add HDMI 2.1 FRL configuration optionsCristian Ciocaltea1-2/+17
The HDMI 2.1 specification introduced the Fixed Rate Link (FRL) mode, aiming to replace the older Transition-Minimized Differential Signaling (TMDS) mode used in previous HDMI versions to support much higher bandwidths (up to 48 Gbps) for modern video and audio formats. FRL has been designed to support ultra high resolution formats at high refresh rates like 8K@60Hz or 4K@120Hz, and eliminates the need for dynamic bandwidth adjustments, which reduces latency. It operates with 3 or 4 lanes at different link rates: 3Gbps, 6Gbps, 8Gbps, 10Gbps or 12Gbps. Add support for configuring the FRL mode for HDMI PHYs. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-1-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: freescale: imx8qm-hsio: fix NULL pointer dereferenceThomas Richard1-1/+1
During the probe the refclk_pad pointer is set to NULL if the 'fsl,refclk-pad-mode' property is not defined in the devicetree node. But in imx_hsio_configure_clk_pad() this pointer is unconditionally used which could result in a NULL pointer dereference. So check the pointer before to use it. Fixes: 82c56b6dd24f ("phy: freescale: imx8qm-hsio: Add i.MX8QM HSIO PHY driver support") Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com> Link: https://patch.msgid.link/20260114-phy-fsl-imx8qm-hsio-fix-null-pointer-dereference-v1-1-730e941be464@bootlin.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: mvebu-cp110-utmi: fix dr_mode property read from dtsAleksandar Gerasimovski1-1/+1
The problem with the current implementation is that it does not consider that the USB controller can have multiple PHY handles with different arguments count, as for example we have in our cn9131 based platform: "phys = <&cp0_comphy1 0>, <&cp0_utmi0>;". In such case calling "of_usb_get_dr_mode_by_phy" with -1 (no phy-cells) leads to not proper phy detection, taking the "marvell,cp110-utmi-phy" dts definition we can call the "of_usb_get_dr_mode_by_phy" with 0 (#phy-cells = <0>) and safely look for that phy. Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@belden.com> Link: https://patch.msgid.link/20260106150643.922110-1-aleksandar.gerasimovski@belden.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: fsl-imx8mq-usb: enable RX Termination overrideXu Yang1-1/+14
This is to resolve the problem of wakeup system by USB3 device insertion if HSIOMIX on, in that case, the USB3 device detects RX term on so the USB3 device doesn't downgrade to high-speed, we can't expect CONN wakeup (for USB3) happen because the 24MHz OSC is required ON to trigger it. Because the device works at Super-speed so DP/DM wakeup can't happen either. Then the entire systen can't be waken up by such device attach event. With this override bit we can force the RX term off when enters system suspend, and disable the override after system resume. Therefore, the USB3 device will always downgrade to High-speed, then DP/DM wakeup can always happen. It will correctly switch to Super-speed later when the host reset it after the system resume back. Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20260116101835.1810675-1-xu.yang_2@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: fsl-imx8mq-usb: set platform driver dataXu Yang1-0/+2
Add missing platform_set_drvdata() as the data will be used in remove(). Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx95") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260120111646.3159766-1-xu.yang_2@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-21phy: fsl-imx8mq-usb: disable bind/unbind platform driver featureXu Yang1-0/+1
Disabling PHYs in runtime usually causes the client with external abort exception or similar issue due to lack of API to notify clients about PHY removal. This patch removes the possibility to unbind i.MX PHY drivers in runtime. Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260120111712.3159782-1-xu.yang_2@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14phy: Add Google Tensor SoC USB PHY driverRoy Luo4-0/+308
Support the USB PHY found on Google Tensor G5 (Laguna). This particular USB PHY supports both high-speed and super-speed operations, and is integrated with the SNPS DWC3 controller that's also on the SoC. This initial patch specifically adds functionality for high-speed. Co-developed-by: Joy Chakraborty <joychakr@google.com> Signed-off-by: Joy Chakraborty <joychakr@google.com> Co-developed-by: Naveen Kumar <mnkumar@google.com> Signed-off-by: Naveen Kumar <mnkumar@google.com> Signed-off-by: Roy Luo <royluo@google.com> Link: https://patch.msgid.link/20251227-phyb4-v10-2-e8caf6b93fe7@google.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: google: Add Google Tensor G5 USB PHYRoy Luo2-0/+134
Document the device tree bindings for the USB PHY interfaces integrated with the DWC3 controller on Google Tensor SoCs, starting with G5 generation (Laguna). The USB PHY on Tensor G5 includes two integrated Synopsys PHY IPs: the eUSB 2.0 PHY IP and the USB 3.2/DisplayPort combo PHY IP. Due to a complete architectural overhaul in the Google Tensor G5, the existing Samsung/Exynos USB PHY binding for older generations of Google silicons such as gs101 are no longer compatible, necessitating this new device tree binding. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Roy Luo <royluo@google.com> Link: https://patch.msgid.link/20251227-phyb4-v10-1-e8caf6b93fe7@google.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14phy: socionext: usb2: Simplify with scoped for each OF child loopKrzysztof Kozlowski1-18/+10
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://patch.msgid.link/20260102124848.64474-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14phy: apple: atc: Reset USB2 PHY during probe as wellSven Peter1-0/+1
Now that the upstream Type-C PHY code is getting broader test coverage we got reports of USB devices plugged in during boot or those plugged in for the first time after boot occasionally not working correctly. This is partially caused by the USB2 parts of the PHY being left in an unknown state by the previous boot stages. We reset all other parts during probe but forgot about the USB2 PHY so let's fix that and actually reset and power off the USB2 PHY as well. Reported-by: James Calligeros <jcalligeros99@gmail.com> Reported-by: Janne Grunau <j@jannau.net> Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY") Signed-off-by: Sven Peter <sven@kernel.org> Reviewed-by: Janne Grunau <j@jannau.net> Tested-by: Janne Grunau <j@jannau.net> Link: https://patch.msgid.link/20260108-atcphy-coldboot-fix-v1-1-01c41c6e84f2@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14phy: apple: atc: Actually check return value of devm_apple_tunable_parseSven Peter1-3/+3
Let's actually check the return value of devm_apple_tunable_parse instead of trying to check IS_ERR on a pointer to the return value which is always going to be valid. This prevent a oops when the tunables are invalid or when they don't exist: [ 57.664567] Unable to handle kernel paging request at virtual address fffffffffffffffe [ 57.664584] Mem abort info: [ 57.664589] ESR = 0x0000000096000007 [ 57.664595] EC = 0x25: DABT (current EL), IL = 32 bits [ 57.664602] SET = 0, FnV = 0 [ 57.664607] EA = 0, S1PTW = 0 [ 57.664611] FSC = 0x07: level 3 translation fault [ 57.664617] Data abort info: [ 57.664621] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 57.664626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 57.664631] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 57.664640] swapper pgtable: 16k pages, 47-bit VAs, pgdp=0000000b4391c000 [ 57.664647] [fffffffffffffffe] pgd=0000000000000000, p4d=0000000000000000, pud=0000000b44188403, pmd=0000000b4418c403, pte=0000000000000000 [ 57.664670] Internal error: Oops: 0000000096000007 [#1] SMP [ 57.665047] CPU: 1 UID: 0 PID: 23 Comm: kworker/1:0 Tainted: G S 6.18.2+ #2 PREEMPTLAZY [ 57.665061] Tainted: [S]=CPU_OUT_OF_SPEC [ 57.665066] Hardware name: Apple Mac mini (M1, 2020) (DT) [ 57.665072] Workqueue: events cd321x_update_work [tps6598x] [ 57.665100] pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 57.665111] pc : apple_tunable_apply+0x8/0x80 [apple_tunable] [ 57.665121] lr : atcphy_mux_set+0x3e0/0x1138 [phy_apple_atc] [ 57.665133] sp : ffffc000802a7c00 [ 57.665138] x29: ffffc000802a7c00 x28: 0000000000000003 x27: ffff800016c84080 [ 57.665151] x26: 0000000000000002 x25: ffff800016c84090 x24: ffff800016c8408f [ 57.665163] x23: 0000000000020004 x22: 0000000000000001 x21: 0000000000000006 [ 57.665175] x20: ffff80000d6da9b0 x19: ffff80000d6da880 x18: 0000000000000002 [ 57.665188] x17: 0000000000000000 x16: ffffe22de59e0e38 x15: 0000000000000002 [ 57.665199] x14: ffffe22de76ecff8 x13: 0000000000000001 x12: ffff9dd5f90bc000 [ 57.665211] x11: 00000000000000c0 x10: 048abc15ceba0919 x9 : ffffe22dbc5fde10 [ 57.665223] x8 : ffff80000175e0d8 x7 : 0000000000000004 x6 : 0000000000000000 [ 57.665234] x5 : 0000000000000001 x4 : 0000000d6d132db7 x3 : 00000000000155db [ 57.665246] x2 : 0000000000000000 x1 : fffffffffffffffe x0 : ffffc00082b80000 [ 57.665258] Call trace: [ 57.665265] apple_tunable_apply+0x8/0x80 [apple_tunable] (P) [ 57.665276] typec_mux_set+0x74/0xe0 [typec] [ 57.665315] cd321x_update_work+0x440/0x8c0 [tps6598x] [ 57.665332] process_one_work+0x178/0x3d0 [ 57.665346] worker_thread+0x260/0x390 [ 57.665354] kthread+0x150/0x250 [ 57.665369] ret_from_fork+0x10/0x20 [ 57.665386] Code: e69a0ae8 ffffe22d aa1e03e9 d503201f (f9400022) [ 57.665394] ---[ end trace 0000000000000000 ]--- Reported-by: Thomas Glanzmann <thomas@glanzmann.de> Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY") Signed-off-by: Sven Peter <sven@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260104-atcphy-tunable-fix-v2-1-84e5c2a57aaa@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14phy: qcom: edp: Fix NULL pointer dereference for phy v6 (x1e80100)Val Packett1-0/+1
For Glymur SoC support, the com_clk_fwd_cfg callback was added, and a stub implementation was added for the v4 of the hardware. However it was omitted for the v6, causing a NULL pointer dereference oops on Hamoa/Purwa (X1E/X1P) SoC devices. Fix by adding the appropriate stub. Fixes: add66a6673bc ("phy: qcom: edp: Add Glymur platform support") Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Yijie Yang <yijie.yang@oss.qualcomm.com> # Purwa-IoT-EVK Link: https://patch.msgid.link/20260111083317.604754-1-val@packett.cool Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14Merge tag 'phy_common_properties' into nextVinod Koul9-103/+858
phy common properties Vladimir Oltean <vladimir.oltean@nxp.com> wrote: Introduce "rx-polarity" and "tx-polarity" device tree properties with Kunit tests
2026-01-14phy: add phy_get_rx_polarity() and phy_get_tx_polarity()Vladimir Oltean6-0/+697
Add helpers in the generic PHY folder which can be used using 'select PHY_COMMON_PROPS' from Kconfig, without otherwise needing to enable GENERIC_PHY. These helpers need to deal with the slight messiness of the fact that the polarity properties are arrays per protocol, and with the fact that there is no default value mandated by the standard properties, all default values depend on driver and protocol (PHY_POL_NORMAL may be a good default for SGMII, whereas PHY_POL_AUTO may be a good default for PCIe). Push the supported mask of polarities to these helpers, to simplify drivers such that they don't need to validate what's in the device tree (or other firmware description). Add a KUnit test suite to make sure that the API produces the expected results. The fact that we use fwnode structures means we can validate with software nodes, and as opposed to the device_property API, we can bypass the need to have a device structure. Co-developed-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260111093940.975359-6-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy-common-props: RX and TX lane polarity inversionVladimir Oltean2-0/+53
Differential signaling is a technique for high-speed protocols to be more resilient to noise. At the transmit side we have a positive and a negative signal which are mirror images of each other. At the receiver, if we subtract the negative signal (say of amplitude -A) from the positive signal (say +A), we recover the original single-ended signal at twice its original amplitude. But any noise, like one coming from EMI from outside sources, is supposed to have an almost equal impact upon the positive (A + E, E being for "error") and negative signal (-A + E). So (A + E) - (-A + E) eliminates this noise, and this is what makes differential signaling useful. Except that in order to work, there must be strict requirements observed during PCB design and layout, like the signal traces needing to have the same length and be physically close to each other, and many others. Sometimes it is not easy to fulfill all these requirements, a simple case to understand is when on chip A's pins, the positive pin is on the left and the negative is on the right, but on the chip B's pins (with which A tries to communicate), positive is on the right and negative on the left. The signals would need to cross, using vias and other ugly stuff that affects signal integrity (introduces impedance discontinuities which cause reflections, etc). So sometimes, board designers intentionally connect differential lanes the wrong way, and expect somebody else to invert that signal to recover useful data. This is where RX and TX polarity inversion comes in as a generic concept that applies to any high-speed serial protocol as long as it uses differential signaling. I've stopped two attempts to introduce more vendor-specific descriptions of this only in the past month: https://lore.kernel.org/linux-phy/20251110110536.2596490-1-horatiu.vultur@microchip.com/ https://lore.kernel.org/netdev/20251028000959.3kiac5kwo5pcl4ft@skbuf/ and in the kernel we already have merged: - "st,px_rx_pol_inv" - "st,pcie-tx-pol-inv" - "st,sata-tx-pol-inv" - "mediatek,pnswap" - "airoha,pnswap-rx" - "airoha,pnswap-tx" and maybe more. So it is pretty general. One additional element of complexity is introduced by the fact that for some protocols, receivers can automatically detect and correct for an inverted lane polarity (example: the PCIe LTSSM does this in the Polling.Configuration state; the USB 3.1 Link Layer Test Specification says that the detection and correction of the lane polarity inversion in SuperSpeed operation shall be enabled in Polling.RxEQ.). Whereas for other protocols (SGMII, SATA, 10GBase-R, etc etc), the polarity is all manual and there is no detection mechanism mandated by their respective standards. So why would one even describe rx-polarity and tx-polarity for protocols like PCIe, if it had to always be PHY_POL_AUTO? Related question: why would we define the polarity as an array per protocol? Isn't the physical PCB layout protocol-agnostic, and aren't we describing the same physical reality from the lens of different protocols? The answer to both questions is because multi-protocol PHYs exist (supporting e.g. USB2 and USB3, or SATA and PCIe, or PCIe and Ethernet over the same lane), one would need to manually set the polarity for SATA/Ethernet, while leaving it at auto for PCIe/USB 3.0+. I also investigated from another angle: what if polarity inversion in the PHY is one layer, and then the PCIe/USB3 LTSSM polarity detection is another layer on top? Then rx-polarity = <PHY_POL_AUTO> doesn't make sense, it can still be rx-polarity = <PHY_POL_NORMAL> or <PHY_POL_INVERT>, and the link training state machine figures things out on top of that. This would radically simplify the design, as the elimination of PHY_POL_AUTO inherently means that the need for a property array per protocol also goes away. I don't know how things are in the general case, but at least in the 10G and 28G Lynx SerDes blocks from NXP Layerscape devices, this isn't the case, and there's only a single level of RX polarity inversion: in the SerDes lane. In the case of PCIe, the controller is in charge of driving the RDAT_INV bit autonomously, and it is read-only to software. So the existence of this kind of SerDes lane proves the need for PHY_POL_AUTO to be a third state. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-5-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy-common-props: ensure protocol-names are uniqueVladimir Oltean1-0/+1
Rob Herring points out that "The default for .*-names is the entries don't have to be unique.": https://lore.kernel.org/linux-phy/20251204155219.GA1533839-robh@kernel.org/ Let's use uniqueItems: true to make sure the schema enforces this. It doesn't make sense in this case to have duplicate properties for the same SerDes protocol. Note that this can only be done with the $defs + $ref pattern as established by the previous commit. When the tx-p2p-microvolt-names constraints were expressed directly under "properties", it would have been validated by the string-array meta-schema, which does not support the 'uniqueItems' keyword as can be seen below. properties:tx-p2p-microvolt-names: Additional properties are not allowed ('uniqueItems' was unexpected) from schema $id: http://devicetree.org/meta-schemas/string-array.yaml Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-4-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy-common-props: create a reusable "protocol-names" definitionVladimir Oltean1-15/+19
Other properties also need to be defined per protocol than just tx-p2p-microvolt-names. Create a common definition to avoid copying a 55 line property. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-3-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yamlVladimir Oltean1-4/+4
I would like to add more properties similar to tx-p2p-microvolt, and I don't think it makes sense to create one schema for each such property (transmit-amplitude.yaml, lane-polarity.yaml, transmit-equalization.yaml etc). Instead, let's rename to phy-common-props.yaml, which makes it a more adequate host schema for all the above properties. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-2-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Add QMP UFS PHY compatiblePradeep P V K1-0/+4
Document QMP UFS PHY compatible for x1e80100 SoC. Use SM8550 as a fallback since x1e80100 is fully compatible with it. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com> Link: https://patch.msgid.link/20260106154207.1871487-2-pradeep.pragallapati@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: qcom,m31-eusb2-phy: Document M31 eUSB2 PHY for KaanapaliRonak Raheja1-0/+1
Document M31 eUSB2 PHY for Kaanapali which handles the USB2 path. Use fallback to indicate the compatibility of the M31 eUSB2 PHY on the Kaanapali with that on the SM8750. Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com> Co-developed-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260108052459.1819970-3-krishna.kurapati@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Add Kaanapali QMP PHYRonak Raheja1-26/+32
Document QMP combo PHY for Kaanapali. Use fallback to indicate the compatibility of the QMP PHY on the Kaanapali with that on the SM8750. Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com> Co-developed-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Link: https://patch.msgid.link/20260108052459.1819970-2-krishna.kurapati@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14phy: cadence-torrent: Add PCIe + XAUI multilink configuration for 100MHz refclkSwapnil Jakhade1-7/+136
Add register sequences for PCIe + XAUI multilink configuration for 100MHz reference clock. The register sequences are fetched from a table by indexing entries based on unique 'keys' generated by the Bitwise OR defined below: REFCLK0_RATE | REFCLK1_RATE | LINK0_TYPE | LINK1_TYPE | SSC_TYPE As of now, LINK_TYPE is a 3-bit value corresponding to the PHY type. With the introduction of TYPE_XAUI, we need a 4-bit value to represent the LINK_TYPE as TYPE_XAUI has the numerical value 8. Hence, extend the LINKx_MASK macros to 4-bit masks. While at it, extend REFCLKx_MASK macros as well to 4-bit masks to support reference clock frequencies that will be added in the future. Adjust the 'LINKx_SHIFT' and the 'REFCLKx_SHIFT' macros to account for the aforementioned changes made to the masks. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> [s-vadapalli: elaborated on changes made to macros in the commit message] Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260112054636.108027-3-s-vadapalli@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: Add PHY_TYPE_XAUI definitionSwapnil Jakhade1-0/+1
XAUI (eXtended Attachment Unit Interface) is a high-speed serial interface standard for 10 Gigabit Ethernet (10GbE). It uses four lanes with each lane operating at 3.125 Gbps (totaling 10 Gbps), to extend the XGMII interface across circuit boards, commonly used in backplanes for networking switches and high-performance computing. XAUI is defined as a standardized instantiation of XGMII Extender in the IEEE 802.3 specification. Add definition for XAUI PHY type. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> [s-vadapalli: added detailed description of XAUI in the commit message] Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260112054636.108027-2-s-vadapalli@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14phy: qcom: qmp-combo: Add polarity inversion support for SAR2130PKrishna Kurapati1-0/+7
On SAR2130P QXR Platform, the CC Lines are inverted and the lane programming is to be done reverse compared to other targets. As per the HW specifics, Bit-2 of TYPEC_CTRL register indicates port select polarity. This bit is to be set for SAR2130P. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20251017203438.744197-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14phy: qcom-qmp-ufs: Add Milos supportLuca Weiss1-0/+96
Add the init sequence tables and config for the UFS QMP phy found in the Milos SoC. Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260112-milos-ufs-v2-4-d3ce4f61f030@fairphone.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Milos QMP UFS PHYLuca Weiss1-0/+2
Document the QMP UFS PHY on the Milos SoC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://patch.msgid.link/20260112-milos-ufs-v2-3-d3ce4f61f030@fairphone.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14phy: sun4i-usb: replace use of system_wq with system_percpu_wqMarco Crivellari1-7/+7
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") Replace system_wq with system_percpu_wq, keeping the same behavior. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251105152023.259813-1-marco.crivellari@suse.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: qcom: edp: Add Glymur platform supportAbel Vesa1-8/+219
The Qualcomm Glymur platform has the new v8 version of the eDP/DP PHY. So rework the driver to support this new version and add the platform specific configuration data. While at it, add the rest of the AUX_CFG reset values for the v4 and v5 platforms, which makes the handling of the platforms specific array cleaner, as they are single sized now. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-glymur-support-v6-4-4fcba75a6fa9@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: qcom-qmp: qserdes-com: Add v8 DP-specific qserdes register offsetsAbel Vesa1-0/+52
Starting with Glymur, the PCIe and DP PHYs qserdes register offsets differ for the same version number. So in order to be able to differentiate between them, add these ones with DP prefix. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-glymur-support-v6-3-4fcba75a6fa9@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: qcom: edp: Fix the DP_PHY_AUX_CFG registers countAbel Vesa1-1/+1
On all platforms supported by this driver, there are 13 DP_PHY_AUX_CFGx registers. This hasn't been an issue so far on currently supported platforms, because the init sequence never spanned beyond DP_PHY_AUX_CFG9. However, on the new upcoming Glymur platform, these are updated along with the rest of the init sequence. So update the size of the array holding the config to 13. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-glymur-support-v6-2-4fcba75a6fa9@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01dt-bindings: phy: Add DP PHY compatible for GlymurAbel Vesa1-0/+2
The Glymur platform is the first one to use the eDP PHY version 8. This makes it incompatible with any of the earlier platforms and therefore requires a dedicated compatible. So document it. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-glymur-support-v6-1-4fcba75a6fa9@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-03 10:52:00 +0300