<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/phy, branch linux-6.15.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>phy: rockchip-pcie: Enable all four lanes if required</title>
<updated>2025-08-20T16:36:17+00:00</updated>
<author>
<name>Valmantas Paliksa</name>
<email>walmis@gmail.com</email>
</author>
<published>2025-06-30T22:25:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6f711fcbb1fe0e0941ee395b786c69f1e054358a'/>
<id>6f711fcbb1fe0e0941ee395b786c69f1e054358a</id>
<content type='text'>
[ 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 &lt;neil.armstrong@linaro.org&gt;
Reviewed-by: Robin Murphy &lt;robin.murphy@arm.com&gt;

Signed-off-by: Valmantas Paliksa &lt;walmis@gmail.com&gt;
Signed-off-by: Geraldo Nascimento &lt;geraldogabriel@gmail.com&gt;
Reviewed-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Reviewed-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://lore.kernel.org/r/16b610aab34e069fd31d9f57260c10df2a968f80.1751322015.git.geraldogabriel@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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 &lt;neil.armstrong@linaro.org&gt;
Reviewed-by: Robin Murphy &lt;robin.murphy@arm.com&gt;

Signed-off-by: Valmantas Paliksa &lt;walmis@gmail.com&gt;
Signed-off-by: Geraldo Nascimento &lt;geraldogabriel@gmail.com&gt;
Reviewed-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Reviewed-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://lore.kernel.org/r/16b610aab34e069fd31d9f57260c10df2a968f80.1751322015.git.geraldogabriel@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: rockchip-pcie: Properly disable TEST_WRITE strobe signal</title>
<updated>2025-08-20T16:36:17+00:00</updated>
<author>
<name>Geraldo Nascimento</name>
<email>geraldogabriel@gmail.com</email>
</author>
<published>2025-06-30T22:25:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e9d1eb59e0acbda68b853ed0b71646050a02a7b5'/>
<id>e9d1eb59e0acbda68b853ed0b71646050a02a7b5</id>
<content type='text'>
[ 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 &lt;neil.armstrong@linaro.org&gt;
Signed-off-by: Geraldo Nascimento &lt;geraldogabriel@gmail.com&gt;
Link: https://lore.kernel.org/r/d514d5d5627680caafa8b7548cbdfee4307f5440.1751322015.git.geraldogabriel@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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 &lt;neil.armstrong@linaro.org&gt;
Signed-off-by: Geraldo Nascimento &lt;geraldogabriel@gmail.com&gt;
Link: https://lore.kernel.org/r/d514d5d5627680caafa8b7548cbdfee4307f5440.1751322015.git.geraldogabriel@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: qualcomm: phy-qcom-eusb2-repeater: Don't zero-out registers</title>
<updated>2025-08-15T10:16:41+00:00</updated>
<author>
<name>Luca Weiss</name>
<email>luca.weiss@fairphone.com</email>
</author>
<published>2025-06-17T08:26:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dda2dd0be8fda0bc837932a835e427007caa2b85'/>
<id>dda2dd0be8fda0bc837932a835e427007caa2b85</id>
<content type='text'>
[ 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 &lt;konrad.dybcio@oss.qualcomm.com&gt;
Reviewed-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Signed-off-by: Luca Weiss &lt;luca.weiss@fairphone.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Reviewed-by: Abel Vesa &lt;abel.vesa@linaro.org&gt;
Link: https://lore.kernel.org/r/20250617-eusb2-repeater-tuning-v2-2-ed6c484f18ee@fairphone.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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 &lt;konrad.dybcio@oss.qualcomm.com&gt;
Reviewed-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Signed-off-by: Luca Weiss &lt;luca.weiss@fairphone.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Reviewed-by: Abel Vesa &lt;abel.vesa@linaro.org&gt;
Link: https://lore.kernel.org/r/20250617-eusb2-repeater-tuning-v2-2-ed6c484f18ee@fairphone.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: use per-PHY lockdep keys</title>
<updated>2025-07-24T06:58:33+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@oss.qualcomm.com</email>
</author>
<published>2025-06-05T11:25:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=37a9cc4e6b9d650bdfab018841a81918a6ae9aa1'/>
<id>37a9cc4e6b9d650bdfab018841a81918a6ae9aa1</id>
<content type='text'>
[ Upstream commit cf0233491b3a15933234a26efd9ecbc1c0764674 ]

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 (&amp;phy-&gt;mutex){+.+.}-{4:4}, at: phy_init+0x4c/0x12c

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

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

        CPU0
        ----
   lock(&amp;phy-&gt;mutex);
   lock(&amp;phy-&gt;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 (&amp;dev-&gt;mutex){....}-{4:4}, at: __device_attach+0x38/0x188
  #3: ffff000813c10cf0 (&amp;phy-&gt;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 &lt;neil.armstrong@linaro.org&gt;
Reviewed-by: Abel Vesa &lt;abel.vesa@linaro.org&gt;
Reported-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Link: https://lore.kernel.org/lkml/ZnpoAVGJMG4Zu-Jw@hovoldconsulting.com/
Reviewed-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Tested-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250605-phy-subinit-v3-1-1e1e849e10cd@oss.qualcomm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit cf0233491b3a15933234a26efd9ecbc1c0764674 ]

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 (&amp;phy-&gt;mutex){+.+.}-{4:4}, at: phy_init+0x4c/0x12c

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

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

        CPU0
        ----
   lock(&amp;phy-&gt;mutex);
   lock(&amp;phy-&gt;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 (&amp;dev-&gt;mutex){....}-{4:4}, at: __device_attach+0x38/0x188
  #3: ffff000813c10cf0 (&amp;phy-&gt;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 &lt;neil.armstrong@linaro.org&gt;
Reviewed-by: Abel Vesa &lt;abel.vesa@linaro.org&gt;
Reported-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Link: https://lore.kernel.org/lkml/ZnpoAVGJMG4Zu-Jw@hovoldconsulting.com/
Reviewed-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Tested-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250605-phy-subinit-v3-1-1e1e849e10cd@oss.qualcomm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: tegra: xusb: Disable periodic tracking on Tegra234</title>
<updated>2025-07-24T06:58:21+00:00</updated>
<author>
<name>Haotien Hsu</name>
<email>haotienh@nvidia.com</email>
</author>
<published>2025-05-19T09:09:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=446e1504cb962aabc06a5bc658f26ca61b92a4ba'/>
<id>446e1504cb962aabc06a5bc658f26ca61b92a4ba</id>
<content type='text'>
commit 7be54870e9bf5ed0b4fe2a23b41a630527882de5 upstream.

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 &lt;haotienh@nvidia.com&gt;
Signed-off-by: Wayne Chang &lt;waynec@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://lore.kernel.org/r/20250519090929.3132456-3-waynec@nvidia.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7be54870e9bf5ed0b4fe2a23b41a630527882de5 upstream.

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 &lt;haotienh@nvidia.com&gt;
Signed-off-by: Wayne Chang &lt;waynec@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://lore.kernel.org/r/20250519090929.3132456-3-waynec@nvidia.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: tegra: xusb: Decouple CYA_TRK_CODE_UPDATE_ON_IDLE from trk_hw_mode</title>
<updated>2025-07-24T06:58:21+00:00</updated>
<author>
<name>Wayne Chang</name>
<email>waynec@nvidia.com</email>
</author>
<published>2025-05-19T09:09:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b12572fda3cbaa084d61fad3dda07dc875a4a1bb'/>
<id>b12572fda3cbaa084d61fad3dda07dc875a4a1bb</id>
<content type='text'>
commit 24c63c590adca310e0df95c77cf7aa5552bc3fc5 upstream.

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 &lt;waynec@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://lore.kernel.org/r/20250519090929.3132456-2-waynec@nvidia.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 24c63c590adca310e0df95c77cf7aa5552bc3fc5 upstream.

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 &lt;waynec@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://lore.kernel.org/r/20250519090929.3132456-2-waynec@nvidia.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY mode</title>
<updated>2025-07-24T06:58:21+00:00</updated>
<author>
<name>Wayne Chang</name>
<email>waynec@nvidia.com</email>
</author>
<published>2025-05-02T09:26:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=eaa420339658615d26c1cc95cd6cf720b9aebfca'/>
<id>eaa420339658615d26c1cc95cd6cf720b9aebfca</id>
<content type='text'>
commit cefc1caee9dd06c69e2d807edc5949b329f52b22 upstream.

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 &lt;waynec@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://lore.kernel.org/r/20250502092606.2275682-1-waynec@nvidia.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cefc1caee9dd06c69e2d807edc5949b329f52b22 upstream.

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 &lt;waynec@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://lore.kernel.org/r/20250502092606.2275682-1-waynec@nvidia.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: fsl-imx8mq-usb: fix phy_tx_vboost_level_from_property()</title>
<updated>2025-06-27T10:13:07+00:00</updated>
<author>
<name>Xu Yang</name>
<email>xu.yang_2@nxp.com</email>
</author>
<published>2025-04-30T09:45:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6fc1ad3d24c5779e87b199a82a9241742cdfe109'/>
<id>6fc1ad3d24c5779e87b199a82a9241742cdfe109</id>
<content type='text'>
commit b15ee09ddb987a122e74fb0fdf1bd6e864959fd3 upstream.

The description of TX_VBOOST_LVL is wrong in register PHY_CTRL3
bit[31:29].

The updated description as below:
  011: Corresponds to a launch amplitude of 0.844 V.
  100: Corresponds to a launch amplitude of 1.008 V.
  101: Corresponds to a launch amplitude of 1.156 V.

This will fix the parsing function
phy_tx_vboost_level_from_property() to return correct value.

Fixes: 63c85ad0cd81 ("phy: fsl-imx8mp-usb: add support for phy tuning")
Cc: stable@vger.kernel.org
Reviewed-by: Jun Li &lt;jun.li@nxp.com&gt;
Signed-off-by: Xu Yang &lt;xu.yang_2@nxp.com&gt;
Link: https://lore.kernel.org/r/20250430094502.2723983-3-xu.yang_2@nxp.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b15ee09ddb987a122e74fb0fdf1bd6e864959fd3 upstream.

The description of TX_VBOOST_LVL is wrong in register PHY_CTRL3
bit[31:29].

The updated description as below:
  011: Corresponds to a launch amplitude of 0.844 V.
  100: Corresponds to a launch amplitude of 1.008 V.
  101: Corresponds to a launch amplitude of 1.156 V.

This will fix the parsing function
phy_tx_vboost_level_from_property() to return correct value.

Fixes: 63c85ad0cd81 ("phy: fsl-imx8mp-usb: add support for phy tuning")
Cc: stable@vger.kernel.org
Reviewed-by: Jun Li &lt;jun.li@nxp.com&gt;
Signed-off-by: Xu Yang &lt;xu.yang_2@nxp.com&gt;
Link: https://lore.kernel.org/r/20250430094502.2723983-3-xu.yang_2@nxp.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: qcom-qusb2: reuse the IPQ6018 settings for IPQ5424</title>
<updated>2025-06-19T13:40:28+00:00</updated>
<author>
<name>Kathiravan Thirumoorthy</name>
<email>kathiravan.thirumoorthy@oss.qualcomm.com</email>
</author>
<published>2025-04-15T04:22:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f006ad318fa7c52c3daa978a04a8782f3dc6f2da'/>
<id>f006ad318fa7c52c3daa978a04a8782f3dc6f2da</id>
<content type='text'>
[ Upstream commit 25c36b54eafc98b3ef004e2037cea1328d9b8bc5 ]

With the settings used in the commit 9c56a1de296e ("phy: qcom-qusb2: add
QUSB2 support for IPQ5424"), compliance test cases especially
eye-diagram (Host High-speed Signal Quality) tests are failing.

Reuse the IPQ6018 settings for IPQ5424 as mentioned in the Hardware
Design Document which helps to meet all the complaince requirement test
cases.

Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424")
Signed-off-by: Kathiravan Thirumoorthy &lt;kathiravan.thirumoorthy@oss.qualcomm.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-2-3a8f86211b59@oss.qualcomm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 25c36b54eafc98b3ef004e2037cea1328d9b8bc5 ]

With the settings used in the commit 9c56a1de296e ("phy: qcom-qusb2: add
QUSB2 support for IPQ5424"), compliance test cases especially
eye-diagram (Host High-speed Signal Quality) tests are failing.

Reuse the IPQ6018 settings for IPQ5424 as mentioned in the Hardware
Design Document which helps to meet all the complaince requirement test
cases.

Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424")
Signed-off-by: Kathiravan Thirumoorthy &lt;kathiravan.thirumoorthy@oss.qualcomm.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-2-3a8f86211b59@oss.qualcomm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "phy: qcom-qusb2: add QUSB2 support for IPQ5424"</title>
<updated>2025-06-19T13:40:27+00:00</updated>
<author>
<name>Kathiravan Thirumoorthy</name>
<email>kathiravan.thirumoorthy@oss.qualcomm.com</email>
</author>
<published>2025-04-15T04:22:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1ec47c5f3cb2d475828754f7b751c40e465b8d69'/>
<id>1ec47c5f3cb2d475828754f7b751c40e465b8d69</id>
<content type='text'>
[ Upstream commit 8a040e13afd94a1f91acaf8e0505769d4f7f5af4 ]

With the current settings, compliance tests especially eye diagram
(Host High-speed Signal Quality) tests are failing. Reuse the IPQ6018
settings to overcome this issue, as mentioned in the Hardware Design
Document.

So revert the change which introduced the new settings and reuse the
IPQ6018 settings in the subsequent patch.

Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424")
Signed-off-by: Kathiravan Thirumoorthy &lt;kathiravan.thirumoorthy@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-1-3a8f86211b59@oss.qualcomm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8a040e13afd94a1f91acaf8e0505769d4f7f5af4 ]

With the current settings, compliance tests especially eye diagram
(Host High-speed Signal Quality) tests are failing. Reuse the IPQ6018
settings to overcome this issue, as mentioned in the Hardware Design
Document.

So revert the change which introduced the new settings and reuse the
IPQ6018 settings in the subsequent patch.

Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424")
Signed-off-by: Kathiravan Thirumoorthy &lt;kathiravan.thirumoorthy@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-1-3a8f86211b59@oss.qualcomm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
