linux.git/include/linux/phy, branch master Linux kernel source tree phy: hdmi: Add HDMI 2.1 FRL configuration options 2026-01-21T08:41:57+00:00 Cristian Ciocaltea cristian.ciocaltea@collabora.com 2026-01-12T23:20:48+00:00 41c6cac6decd5123db1da8ca240a9c808b0ae6ce 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> 
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>
Merge tag 'phy_common_properties' into next 2026-01-14T13:22:57+00:00 Vinod Koul vkoul@kernel.org 2026-01-14T13:22:57+00:00 a699808928937000e550a7cd5355db93ef99e236 phy common properties Vladimir Oltean <vladimir.oltean@nxp.com> wrote: Introduce "rx-polarity" and "tx-polarity" device tree properties with Kunit tests 
phy common properties

Vladimir Oltean <vladimir.oltean@nxp.com> wrote:

Introduce "rx-polarity" and "tx-polarity" device tree properties with
Kunit tests
phy: add phy_get_rx_polarity() and phy_get_tx_polarity() 2026-01-14T12:46:05+00:00 Vladimir Oltean vladimir.oltean@nxp.com 2026-01-11T09:39:34+00:00 e7556b59ba65179612bce3fa56bb53d1b4fb20db 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> 
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>
phy: core: Discard pm_runtime_put() return values 2025-12-23T17:41:03+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-12-22T20:22:48+00:00 caad07ae07e3fb173e804abdd53fb96aa7186830 The PHY core defines phy_pm_runtime_put() to return an int, but that return value is never used. It also passes the return value of pm_runtime_put() to the caller which is not very useful. Returning an error code from pm_runtime_put() merely means that it has not queued up a work item to check whether or not the device can be suspended and there are many perfectly valid situations in which that can happen, like after writing "on" to the devices' runtime PM "control" attribute in sysfs for one example. Modify phy_pm_runtime_put() to discard the pm_runtime_put() return value and change its return type to void. Also drop the redundant pm_runtime_enabled() call from there. No intentional functional impact. This will facilitate a planned change of the pm_runtime_put() return type to void in the future. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2556645.jE0xQCEvom@rafael.j.wysocki Signed-off-by: Vinod Koul <vkoul@kernel.org> 
The PHY core defines phy_pm_runtime_put() to return an int, but that
return value is never used.  It also passes the return value of
pm_runtime_put() to the caller which is not very useful.

Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.

Modify phy_pm_runtime_put() to discard the pm_runtime_put() return
value and change its return type to void.  Also drop the redundant
pm_runtime_enabled() call from there.

No intentional functional impact.

This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2556645.jE0xQCEvom@rafael.j.wysocki
Signed-off-by: Vinod Koul <vkoul@kernel.org>
phy: add new phy_notify_state() api 2025-11-18T16:56:02+00:00 Peter Griffin peter.griffin@linaro.org 2025-11-12T16:27:06+00:00 4edf654be5471659e3260be0a557eaa2ece668ab Add a new phy_notify_state() api that notifies and configures a phy for a given state transition. This is intended to be used by phy drivers which need to do some runtime configuration of parameters that can't be handled by phy_calibrate() or phy_power_{on|off}(). The first usage of this API is in the Samsung UFS phy that needs to issue some register writes when entering and exiting the hibernate link state. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251112-phy-notify-pmstate-v5-1-39df622d8fcb@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Add a new phy_notify_state() api that notifies and configures a phy for a
given state transition.

This is intended to be used by phy drivers which need to do some runtime
configuration of parameters that can't be handled by phy_calibrate() or
phy_power_{on|off}().

The first usage of this API is in the Samsung UFS phy that needs to issue
some register writes when entering and exiting the hibernate link state.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251112-phy-notify-pmstate-v5-1-39df622d8fcb@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
phy: use per-PHY lockdep keys 2025-06-15T15:49:08+00:00 Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com 2025-06-05T11:25:49+00:00 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 (&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 <neil.armstrong@linaro.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reported-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/lkml/ZnpoAVGJMG4Zu-Jw@hovoldconsulting.com/ Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250605-phy-subinit-v3-1-1e1e849e10cd@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
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 <neil.armstrong@linaro.org>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reported-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/lkml/ZnpoAVGJMG4Zu-Jw@hovoldconsulting.com/
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250605-phy-subinit-v3-1-1e1e849e10cd@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
phy: hdmi: Add color depth configuration 2025-04-11T11:48:03+00:00 Cristian Ciocaltea cristian.ciocaltea@collabora.com 2025-03-18T12:35:36+00:00 3bb9286f4ece6acbc1fbaa9f192a82645d30efbf Extend the HDMI configuration options to allow managing bits per color channel. This is required by some PHY drivers such as rockchip-samsung-hdptx. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-2-8cb1678e7663@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Extend the HDMI configuration options to allow managing bits per color
channel.  This is required by some PHY drivers such as
rockchip-samsung-hdptx.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-2-8cb1678e7663@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
phy: Add HDMI configuration options 2025-04-11T11:48:03+00:00 Sandor Yu Sandor.yu@nxp.com 2025-03-18T12:35:35+00:00 10ed34d6eaaf86e301a8f2dd190d26dfbc9799bd Allow HDMI PHYs to be configured through the generic functions through a custom structure added to the generic union. The parameters added here are based on HDMI PHY implementation practices. The current set of parameters should cover the potential users. Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/d1cff6c03ec3732d2244022029245ab2d954d997.1734340233.git.Sandor.yu@nxp.com Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-1-8cb1678e7663@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Allow HDMI PHYs to be configured through the generic
functions through a custom structure added to the generic union.

The parameters added here are based on HDMI PHY
implementation practices.  The current set of parameters
should cover the potential users.

Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/d1cff6c03ec3732d2244022029245ab2d954d997.1734340233.git.Sandor.yu@nxp.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-1-8cb1678e7663@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
phy: core: Remove unused phy_pm_runtime_(allow|forbid) 2025-03-10T07:28:07+00:00 Dr. David Alan Gilbert linux@treblig.org 2025-03-06T01:54:08+00:00 b02d41d884f64d22d5d5a2a4b35550f5e80bdb3d phy_pm_runtime_allow() and phy_pm_runtime_forbid() were added in 2013 as part of commit ff764963479a ("drivers: phy: add generic PHY framework") but have remained unused. Remove them. Fix up the (English) docs - I've left the Chinese translation. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250306015408.277729-1-linux@treblig.org Signed-off-by: Vinod Koul <vkoul@kernel.org> 
phy_pm_runtime_allow() and phy_pm_runtime_forbid() were added in 2013
as part of
commit ff764963479a ("drivers: phy: add generic PHY framework")
but have remained unused.

Remove them.
Fix up the (English) docs - I've left the Chinese translation.

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20250306015408.277729-1-linux@treblig.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
phy: sun4i-usb: Fix a typo 2024-10-11T09:07:29+00:00 Andrew Kreimer algonell@gmail.com 2024-10-10T09:13:55+00:00 11dad94b50263bbe87d015041c77be61c8c44161 Fix a typo in comments: wether -> whether. Signed-off-by: Andrew Kreimer <algonell@gmail.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20241010091355.8271-1-algonell@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Fix a typo in comments: wether -> whether.

Signed-off-by: Andrew Kreimer <algonell@gmail.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20241010091355.8271-1-algonell@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>