linux-stable.git/drivers/phy, branch v6.16.2

phy: rockchip-pcie: Enable all four lanes if required

2025-08-20T16:41:22+00:00

[ Upstream commit c3fe7071e196e25789ecf90dbc9e8491a98884d7 ]

Current code enables only Lane 0 because pwr_cnt will be incremented on
first call to the function. Let's reorder the enablement code to enable
all 4 lanes through GRF.

Reviewed-by: Neil Armstrong 
Reviewed-by: Robin Murphy 

Signed-off-by: Valmantas Paliksa 
Signed-off-by: Geraldo Nascimento 
Reviewed-by: Robin Murphy 
Reviewed-by: Neil Armstrong 
Link: https://lore.kernel.org/r/16b610aab34e069fd31d9f57260c10df2a968f80.1751322015.git.geraldogabriel@gmail.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: rockchip-pcie: Properly disable TEST_WRITE strobe signal

2025-08-20T16:41:22+00:00

[ Upstream commit 25facbabc3fc33c794ad09d73f73268c0f8cbc7d ]

pcie_conf is used to touch TEST_WRITE strobe signal. This signal should
be enabled, a little time waited, and then disabled. Current code clearly
was copy-pasted and never disables the strobe signal. Adjust the define.
While at it, remove PHY_CFG_RD_MASK which has been unused since
64cdc0360811 ("phy: rockchip-pcie: remove unused phy_rd_cfg function").

Reviewed-by: Neil Armstrong 
Signed-off-by: Geraldo Nascimento 
Link: https://lore.kernel.org/r/d514d5d5627680caafa8b7548cbdfee4307f5440.1751322015.git.geraldogabriel@gmail.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: qcom: phy-qcom-snps-eusb2: Add missing write from init sequence

2025-08-15T14:39:10+00:00

[ Upstream commit 7f5f703210109366c1e1b685086c9b0a4897ea54 ]

As per a commit from Qualcomm's downstream 6.1 kernel[0], the init
sequence is missing setting the CMN_CTRL_OVERRIDE_EN bit back to 0 at
the end, as per the 'latest' HPG revision (as of November 2023).

[0] https://git.codelinaro.org/clo/la/kernel/qcom/-/commit/b77774a89e3fda3246e09dd39e16e2ab43cd1329

Fixes: 80090810f5d3 ("phy: qcom: Add QCOM SNPS eUSB2 driver")
Reviewed-by: Konrad Dybcio 
Reviewed-by: Neil Armstrong 
Signed-off-by: Luca Weiss 
Link: https://lore.kernel.org/r/20250715-sm7635-eusb-phy-v3-3-6c3224085eb6@fairphone.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: qualcomm: phy-qcom-eusb2-repeater: Don't zero-out registers

2025-08-15T14:39:01+00:00

[ Upstream commit 31bc94de76026c527f82c238f414539a14f0f3e6 ]

Zeroing out registers does not happen in the downstream kernel, and will
"tune" the repeater in surely unexpected ways since most registers don't
have a reset value of 0x0.

Stop doing that and instead just set the registers that are in the init
sequence (though long term I don't think there's actually PMIC-specific
init sequences, there's board specific tuning, but that's a story for
another day).

Fixes: 99a517a582fc ("phy: qualcomm: phy-qcom-eusb2-repeater: Zero out untouched tuning regs")
Reviewed-by: Konrad Dybcio 
Reviewed-by: Neil Armstrong 
Signed-off-by: Luca Weiss 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abel Vesa 
Link: https://lore.kernel.org/r/20250617-eusb2-repeater-tuning-v2-2-ed6c484f18ee@fairphone.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: qcom: fix error code in snps_eusb2_hsphy_probe()

2025-07-15T15:06:47+00:00

When phy->ref_clk is NULL PTR_ERR(NULL) will be a success. Fix this by
using -ENOENT when phy->ref_clk is NULL instead.

Fixes: 80090810f5d3 ("phy: qcom: Add QCOM SNPS eUSB2 driver")
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/all/aDCbeuCTy9zyWJAM@stanley.mountain/
Signed-off-by: Harshit Mogalapalli 
Link: https://lore.kernel.org/r/20250710172403.2593193-1-harshit.m.mogalapalli@oracle.com
Signed-off-by: Vinod Koul

phy: use per-PHY lockdep keys

2025-06-15T15:49:08+00:00

If the PHY driver uses another PHY internally (e.g. in case of eUSB2,
repeaters are represented as PHYs), then it would trigger the following
lockdep splat because all PHYs use a single static lockdep key and thus
lockdep can not identify whether there is a dependency or not and
reports a false positive.

Make PHY subsystem use dynamic lockdep keys, assigning each driver a
separate key. This way lockdep can correctly identify dependency graph
between mutexes.

 ============================================
 WARNING: possible recursive locking detected
 6.15.0-rc7-next-20250522-12896-g3932f283970c #3455 Not tainted
 --------------------------------------------
 kworker/u51:0/78 is trying to acquire lock:
 ffff0008116554f0 (&phy->mutex){+.+.}-{4:4}, at: phy_init+0x4c/0x12c

 but task is already holding lock:
 ffff000813c10cf0 (&phy->mutex){+.+.}-{4:4}, at: phy_init+0x4c/0x12c

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&phy->mutex);
   lock(&phy->mutex);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 4 locks held by kworker/u51:0/78:
  #0: ffff000800010948 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x18c/0x5ec
  #1: ffff80008036bdb0 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1b4/0x5ec
  #2: ffff0008094ac8f8 (&dev->mutex){....}-{4:4}, at: __device_attach+0x38/0x188
  #3: ffff000813c10cf0 (&phy->mutex){+.+.}-{4:4}, at: phy_init+0x4c/0x12c

 stack backtrace:
 CPU: 0 UID: 0 PID: 78 Comm: kworker/u51:0 Not tainted 6.15.0-rc7-next-20250522-12896-g3932f283970c #3455 PREEMPT
 Hardware name: Qualcomm CRD, BIOS 6.0.240904.BOOT.MXF.2.4-00528.1-HAMOA-1 09/ 4/2024
 Workqueue: events_unbound deferred_probe_work_func
 Call trace:
  show_stack+0x18/0x24 (C)
  dump_stack_lvl+0x90/0xd0
  dump_stack+0x18/0x24
  print_deadlock_bug+0x258/0x348
  __lock_acquire+0x10fc/0x1f84
  lock_acquire+0x1c8/0x338
  __mutex_lock+0xb8/0x59c
  mutex_lock_nested+0x24/0x30
  phy_init+0x4c/0x12c
  snps_eusb2_hsphy_init+0x54/0x1a0
  phy_init+0xe0/0x12c
  dwc3_core_init+0x450/0x10b4
  dwc3_core_probe+0xce4/0x15fc
  dwc3_probe+0x64/0xb0
  platform_probe+0x68/0xc4
  really_probe+0xbc/0x298
  __driver_probe_device+0x78/0x12c
  driver_probe_device+0x3c/0x160
  __device_attach_driver+0xb8/0x138
  bus_for_each_drv+0x84/0xe0
  __device_attach+0x9c/0x188
  device_initial_probe+0x14/0x20
  bus_probe_device+0xac/0xb0
  deferred_probe_work_func+0x8c/0xc8
  process_one_work+0x208/0x5ec
  worker_thread+0x1c0/0x368
  kthread+0x14c/0x20c
  ret_from_fork+0x10/0x20

Fixes: 3584f6392f09 ("phy: qcom: phy-qcom-snps-eusb2: Add support for eUSB2 repeater")
Fixes: e2463559ff1d ("phy: amlogic: Add Amlogic AXG PCIE PHY Driver")
Reviewed-by: Neil Armstrong 
Reviewed-by: Abel Vesa 
Reported-by: Johan Hovold 
Link: https://lore.kernel.org/lkml/ZnpoAVGJMG4Zu-Jw@hovoldconsulting.com/
Reviewed-by: Johan Hovold 
Tested-by: Johan Hovold 
Signed-off-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20250605-phy-subinit-v3-1-1e1e849e10cd@oss.qualcomm.com
Signed-off-by: Vinod Koul

phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY mode

2025-06-15T14:18:56+00:00

When transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the code
assumed that the regulator should be disabled. However, if the regulator
is marked as always-on, regulator_is_enabled() continues to return true,
leading to an incorrect attempt to disable a regulator which is not
enabled.

This can result in warnings such as:

[  250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004
_regulator_disable+0xe4/0x1a0
[  250.155652] unbalanced disables for VIN_SYS_5V0

To fix this, we move the regulator control logic into
tegra186_xusb_padctl_id_override() function since it's directly related
to the ID override state. The regulator is now only disabled when the role
transitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_ID
register. This ensures that regulator enable/disable operations are
properly balanced and only occur when actually transitioning to/from host
mode.

Fixes: 49d46e3c7e59 ("phy: tegra: xusb: Add set_mode support for UTMI phy on Tegra186")
Cc: stable@vger.kernel.org
Signed-off-by: Wayne Chang 
Reviewed-by: Jon Hunter 
Tested-by: Jon Hunter 
Link: https://lore.kernel.org/r/20250502092606.2275682-1-waynec@nvidia.com
Signed-off-by: Vinod Koul

phy: tegra: xusb: Disable periodic tracking on Tegra234

2025-06-15T14:16:02+00:00

Periodic calibration updates (~10µs) may overlap with transfers when
PCIe NVMe SSD, LPDDR, and USB2 devices operate simultaneously, causing
crosstalk on Tegra234 devices. Hence disable periodic calibration updates
and make this a one-time calibration.

Fixes: d8163a32ca95 ("phy: tegra: xusb: Add Tegra234 support")
Cc: stable@vger.kernel.org
Signed-off-by: Haotien Hsu 
Signed-off-by: Wayne Chang 
Reviewed-by: Jon Hunter 
Tested-by: Jon Hunter 
Link: https://lore.kernel.org/r/20250519090929.3132456-3-waynec@nvidia.com
Signed-off-by: Vinod Koul

phy: tegra: xusb: Decouple CYA_TRK_CODE_UPDATE_ON_IDLE from trk_hw_mode

2025-06-15T14:16:01+00:00

The logic that drives the pad calibration values resides in the
controller reset domain and so the calibration values are only being
captured when the controller is out of reset. However, by clearing the
CYA_TRK_CODE_UPDATE_ON_IDLE bit, the calibration values can be set
while the controller is in reset.

The CYA_TRK_CODE_UPDATE_ON_IDLE bit was previously cleared based on the
trk_hw_mode flag, but this dependency is not necessary. Instead,
introduce a new flag, trk_update_on_idle, to independently control this
bit.

Fixes: d8163a32ca95 ("phy: tegra: xusb: Add Tegra234 support")
Cc: stable@vger.kernel.org
Signed-off-by: Wayne Chang 
Reviewed-by: Jon Hunter 
Tested-by: Jon Hunter 
Link: https://lore.kernel.org/r/20250519090929.3132456-2-waynec@nvidia.com
Signed-off-by: Vinod Koul

Merge tag 'phy-for-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy

2025-06-05T15:20:21+00:00

Pull phy updates from Vinod Koul:
 "As usual featuring couple of new driver and bunch of new device
  support and some driver changes to Freescale, rockchip driver along
  with couple of yaml binding conversions.

  New Support:
   - Qualcomm IPQ5424 qusb2 support, IPQ5018 uniphy-pcie driver
   - Rockchip usb2 support for RK3562, RK3036 usb2 phy support
   - Samsung exynos2200 eusb2 phy support and driver refactoring for
     this support, exynos7870 USBDRD support
   - Mediatek MT7988 xs-phy support
   - Broadcom BCM74110 usb phy support
   - Renesas RZ/V2H(P) usb2 phy support

  Updates:
   - Freescale phy rate claculation updates, i.MX95 tuning support
   - Better error handling for amlogic pcie phy
   - Rockchip color depth configuration and management support
   - Yaml binding conversion for RK3399 Type-C and PCIe Phy"

* tag 'phy-for-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (77 commits)
  phy: tegra: p2u: Broaden architecture dependency
  phy: rockchip: inno-usb2: Add usb2 phy support for rk3562
  dt-bindings: phy: rockchip,inno-usb2phy: add rk3562
  phy: rockchip: inno-usb2: add phy definition for rk3036
  dt-bindings: phy: rockchip,inno-usb2phy: add rk3036 compatible
  phy: freescale: fsl-samsung-hdmi: Improve LUT search for best clock
  phy: freescale: fsl-samsung-hdmi: Refactor finding PHY settings
  phy: freescale: fsl-samsung-hdmi: Rename phy_clk_round_rate
  phy: renesas: phy-rcar-gen3-usb2: Add USB2.0 PHY support for RZ/V2H(P)
  phy: renesas: phy-rcar-gen3-usb2: Sort compatible entries by SoC part number
  dt-bindings: phy: renesas,usb2-phy: Document RZ/V2H(P) SoC
  dt-bindings: phy: renesas,usb2-phy: Add clock constraint for RZ/G2L family
  phy: exynos5-usbdrd: support Exynos USBDRD 3.2 4nm controller
  phy: phy-snps-eusb2: add support for exynos2200
  phy: phy-snps-eusb2: refactor reference clock init
  phy: phy-snps-eusb2: make reset control optional
  phy: phy-snps-eusb2: make repeater optional
  phy: phy-snps-eusb2: split phy init code
  phy: phy-snps-eusb2: refactor constructs names
  phy: move phy-qcom-snps-eusb2 out of its vendor sub-directory
  ...