linux-rng/include/linux/phy, branch master

phy: hdmi: Add optional FRL TxFFE config options

2026-10-04T10:53:45Z

During HDMI 2.1 FRL link training, the source and sink can negotiate a Transmitter Feed-Forward Equalization (TxFFE) level to improve the signal quality. Starting from zero, the source may increment the TxFFE level up to a maximum agreed during the LTS3 stage if the sink keeps reporting FLT failures. TxFFE adjustment is optional and only attempted when both the source and the connected sink support it. Since the existing HDMI PHY configuration API covers the FRL rate/lane selection only, provide the following fields to the frl sub-struct of phy_configure_opts_hdmi: * ffe_level: the TxFFE level to apply, only meaningful when set_ffe_level is set. * set_ffe_level: a 1-bit flag that changes the semantics of the phy_configure() call, i.e. when set, the PHY driver must apply the new ffe_level and ignore the other frl related fields. The flag-based approach reflects an important invariant in the link training process: whenever the FRL rate or lane count changes, the TxFFE level must be reset to zero. A separate phy_configure() call with set_ffe_level can only follow after the rate has been established, making the two operations deliberately distinct. Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20260901-hdptx-ffe-v2-1-3a5922c76fc5@collabora.com Signed-off-by: Vinod Koul

phy: fix typos in comments

2026-10-03T15:10:13Z

Fix typos in comments, reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam Link: https://patch.msgid.link/20260907062518.12810-1-hemanth.selam@gmail.com Signed-off-by: Vinod Koul

Merge branch 'topic/phy_qcom_camss' into next

2026-09-23T12:37:19Z

phy: core: Add devm_phy_get_by_of_node()

2026-09-23T12:30:28Z

Add a devm variant of phy_get_by_of_node() to allow for the familiar pattern of having devres automatically release resources on the driver's exit path. Reviewed-by: Manivannan Sadhasivam Signed-off-by: Bryan O'Donoghue Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260918-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v20-3-dc244e124e71@linaro.org Signed-off-by: Vinod Koul

phy: core: Add phy_get_by_of_node()

2026-09-23T12:30:28Z

Add new function phy_get_by_of_node() allowing lookup of a phy by device_node. Separates existing logic in _of_phy_get() into an internal helper method _of_phy_get_with_args() to allow for reuse in new method. Signed-off-by: Bryan O'Donoghue Reviewed-by: Manivannan Sadhasivam Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260918-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v20-2-dc244e124e71@linaro.org Signed-off-by: Vinod Koul

phy: core: Define TBT phy_mode

2026-09-15T06:25:54Z

There exist OS-accessible USB4 and Thunderbolt PHYs that need specific configuration. Define a new phy_mode for them. Currently, USB4 and TBT3 are defined as submodes, because they're quite distinct, most visibly in the electrical/analog aspects (slightly different frequencies, timings, etc.). This results in a need to make the PHY aware of the actual mode needed (at least in the Qualcomm implementation, but I believe that'll be a general need). Newer versions of TBT are basically supersets of USB4 with higher host-side requirements, so these are not defined. This can always be changed as necessary. Reviewed-by: Dmitry Baryshkov Reviewed-by: Manivannan Sadhasivam Signed-off-by: Konrad Dybcio Link: https://patch.msgid.link/20260908-topic-usb4phy-v5-2-73aac69578ef@oss.qualcomm.com Signed-off-by: Vinod Koul

phy: hdmi: Add HDMI 2.1 FRL configuration options

2026-01-21T08:41:57Z

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 Link: https://patch.msgid.link/20260113-phy-hdptx-frl-v6-1-8d5f97419c0b@collabora.com Signed-off-by: Vinod Koul

Merge tag 'phy_common_properties' into next

2026-01-14T13:22:57Z

phy common properties Vladimir Oltean 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:05Z

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 Signed-off-by: Bjørn Mork Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260111093940.975359-6-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul

phy: core: Discard pm_runtime_put() return values

2025-12-23T17:41:03Z

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 Link: https://patch.msgid.link/2556645.jE0xQCEvom@rafael.j.wysocki Signed-off-by: Vinod Koul