Charan Pedumuru [Fri, 23 Jan 2026 15:39:03 +0000 (15:39 +0000)]
dt-bindings: phy: ti,phy-usb3: convert to DT schema
Convert TI PIPE3 PHY binding to DT schema.
Changes during conversion:
- Define a new pattern 'pcie-phy' to match nodes defined in DT.
- Drop obsolete "id" property from the schema.
Commit bbf711682cd5 ("phy: tegra: xusb: Add Tegra186 support") added the
variable 'powered_on' to the structure 'tegra_xusb_usb2_lane' but it has
never been used. Therefore, remove this unused variable.
The driver start registering a regulator, but can still be
enabled even when it is unable to call into the regulator
subsystem:
aarch64-linux-ld: drivers/phy/renesas/phy-rcar-gen3-usb2.o: in function `rcar_gen3_phy_usb2_probe':
phy-rcar-gen3-usb2.c:(.text+0x2884): undefined reference to `devm_regulator_register'
Add a Kconfig dependency to avoid this configuration.
Arnd Bergmann [Mon, 2 Feb 2026 09:56:52 +0000 (10:56 +0100)]
phy: GOOGLE_USB: add TYPEC dependency
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>
Vladimir Oltean [Fri, 23 Jan 2026 11:06:00 +0000 (13:06 +0200)]
phy: enter drivers/phy/Makefile even without CONFIG_GENERIC_PHY
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.
Tommaso Merciai [Mon, 22 Dec 2025 13:43:47 +0000 (14:43 +0100)]
phy: renesas: rcar-gen3-usb2: Use mux-state for phyrst management
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.
Tommaso Merciai [Mon, 22 Dec 2025 13:43:46 +0000 (14:43 +0100)]
phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control
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.
Tommaso Merciai [Mon, 22 Dec 2025 13:43:45 +0000 (14:43 +0100)]
phy: renesas: rcar-gen3-usb2: Use devm_pm_runtime_enable()
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.
Tommaso Merciai [Mon, 22 Dec 2025 13:43:44 +0000 (14:43 +0100)]
phy: renesas: rcar-gen3-usb2: Factor out VBUS control logic
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.
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.
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.
phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support
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.
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.
phy: rockchip: samsung-hdptx: Switch to driver specific HDMI config
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.
phy: rockchip: samsung-hdptx: Drop hw_rate driver data
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.
phy: rockchip: samsung-hdptx: Compute clk rate from PLL config
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.
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.
phy: rockchip: samsung-hdptx: Enable lane output in common helper
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().
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.
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.
phy: mvebu-cp110-utmi: fix dr_mode property read from dts
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.
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.
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.
Roy Luo [Sat, 27 Dec 2025 00:53:29 +0000 (00:53 +0000)]
phy: Add Google Tensor SoC USB PHY driver
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>
Roy Luo [Sat, 27 Dec 2025 00:53:28 +0000 (00:53 +0000)]
dt-bindings: phy: google: Add Google Tensor G5 USB PHY
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.
Sven Peter [Thu, 8 Jan 2026 19:12:06 +0000 (20:12 +0100)]
phy: apple: atc: Reset USB2 PHY during probe as well
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>
Sven Peter [Sun, 4 Jan 2026 21:56:39 +0000 (22:56 +0100)]
phy: apple: atc: Actually check return value of devm_apple_tunable_parse
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:
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>
Vladimir Oltean [Sun, 11 Jan 2026 09:39:34 +0000 (11:39 +0200)]
phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
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.
Vladimir Oltean [Sun, 11 Jan 2026 09:39:33 +0000 (11:39 +0200)]
dt-bindings: phy-common-props: RX and TX lane polarity inversion
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.
Vladimir Oltean [Sun, 11 Jan 2026 09:39:32 +0000 (11:39 +0200)]
dt-bindings: phy-common-props: ensure protocol-names are unique
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
Vladimir Oltean [Sun, 11 Jan 2026 09:39:31 +0000 (11:39 +0200)]
dt-bindings: phy-common-props: create a reusable "protocol-names" definition
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.
Vladimir Oltean [Sun, 11 Jan 2026 09:39:30 +0000 (11:39 +0200)]
dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml
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.
Ronak Raheja [Thu, 8 Jan 2026 05:24:59 +0000 (10:54 +0530)]
dt-bindings: phy: qcom,m31-eusb2-phy: Document M31 eUSB2 PHY for Kaanapali
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>
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>
Swapnil Jakhade [Mon, 12 Jan 2026 05:46:30 +0000 (11:16 +0530)]
dt-bindings: phy: Add PHY_TYPE_XAUI definition
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>
phy: sun4i-usb: replace use of system_wq with system_percpu_wq
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.
Abel Vesa [Wed, 24 Dec 2025 11:10:47 +0000 (13:10 +0200)]
phy: qcom: edp: Add Glymur platform support
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.
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.
Abel Vesa [Wed, 24 Dec 2025 11:10:45 +0000 (13:10 +0200)]
phy: qcom: edp: Fix the DP_PHY_AUX_CFG registers count
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.
Abel Vesa [Wed, 24 Dec 2025 11:10:44 +0000 (13:10 +0200)]
dt-bindings: phy: Add DP PHY compatible for Glymur
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.
Abel Vesa [Wed, 24 Dec 2025 10:53:28 +0000 (12:53 +0200)]
phy: qcom: edp: Make the number of clocks flexible
On X Elite, the DP PHY needs another clock called ref, while all other
platforms do not.
The current X Elite devices supported upstream work fine without this
clock, because the boot firmware leaves this clock enabled. But we should
not rely on that. Also, even though this change breaks the ABI, it is
needed in order to make the driver disables this clock along with the
other ones, for a proper bring-down of the entire PHY.
So in order to handle these clocks on different platforms, make the driver
get all the clocks regardless of how many there are provided.
Cc: stable@vger.kernel.org # v6.10 Fixes: db83c107dc29 ("phy: qcom: edp: Add v6 specific ops and X1E80100 platform support") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-missing-refclk-v5-2-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Abel Vesa [Wed, 24 Dec 2025 10:53:27 +0000 (12:53 +0200)]
dt-bindings: phy: qcom-edp: Add missing clock for X Elite
On X Elite platform, the eDP PHY uses one more clock called ref.
The current X Elite devices supported upstream work fine without this
clock, because the boot firmware leaves this clock enabled. But we should
not rely on that. Also, even though this change breaks the ABI, it is
needed in order to make the driver disables this clock along with the
other ones, for a proper bring-down of the entire PHY.
Ze Huang [Fri, 17 Oct 2025 14:49:53 +0000 (22:49 +0800)]
phy: spacemit: support K1 USB2.0 PHY controller
The SpacemiT K1 SoC includes three USB ports:
- One USB2.0 OTG port
- One USB2.0 host-only port
- One USB3.0 port with an integrated USB2.0 DRD interface
Each of these ports is connected to a USB2.0 PHY responsible for USB2
transmission.
This commit adds support for the SpacemiT K1 USB2.0 PHY, which is
compliant with the USB 2.0 specification and supports both 8-bit 60MHz
and 16-bit 30MHz parallel interfaces.
While phy_pm_runtime_get{,_sync}() and phy_pm_runtime_put_sync() still
contain pm_runtime_enabled() checks, the same check in
phy_pm_runtime_put() was deemed redundant and removed, causing count
underflows with PHY drivers like drivers/phy/renesas/phy-rcar-gen2.c
that do not use Runtime PM yet,
Alex Elder [Fri, 26 Dec 2025 17:32:27 +0000 (11:32 -0600)]
phy: Kconfig: spacemit: add COMMON_CLK dependency
The SpacemiT PCIe PHY driver depends on the common clock framework.
Not specifying that led to a failure when doing a COMPILE_TEST build
for the SPARC architecture.
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512251903.sTVZgg6c-lkp@intel.com/ Signed-off-by: Alex Elder <elder@riscstar.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20251226173228.2020411-1-elder@riscstar.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Brian Masney [Thu, 11 Dec 2025 23:16:27 +0000 (08:16 +0900)]
phy: ti: phy-j721e-wiz: convert from round_rate() to determine_rate()
The round_rate() clk ops is deprecated, so migrate this driver from
round_rate() to determine_rate() using the Coccinelle semantic patch
on the cover letter of this series.
Brian Masney [Thu, 11 Dec 2025 23:16:26 +0000 (08:16 +0900)]
phy: rockchip: phy-rockchip-samsung-hdptx: convert from round_rate() to determine_rate()
The round_rate() clk ops is deprecated, so migrate this driver from
round_rate() to determine_rate() using the Coccinelle semantic patch
on the cover letter of this series.
Brian Masney [Thu, 11 Dec 2025 23:16:25 +0000 (08:16 +0900)]
phy: rockchip: phy-rockchip-inno-hdmi: convert from round_rate() to determine_rate()
The round_rate() clk ops is deprecated, so migrate this driver from
round_rate() to determine_rate() using the Coccinelle semantic patch
on the cover letter of this series.
Brian Masney [Thu, 11 Dec 2025 23:16:24 +0000 (08:16 +0900)]
phy: mediatek: phy-mtk-mipi-dsi-mt8183: convert from round_rate() to determine_rate()
The round_rate() clk ops is deprecated, so migrate this driver from
round_rate() to determine_rate() using the Coccinelle semantic patch
on the cover letter of this series.
Brian Masney [Thu, 11 Dec 2025 23:16:23 +0000 (08:16 +0900)]
phy: mediatek: phy-mtk-mipi-dsi-mt8173: convert from round_rate() to determine_rate()
The round_rate() clk ops is deprecated, so migrate this driver from
round_rate() to determine_rate() using the Coccinelle semantic patch
on the cover letter of this series.
Brian Masney [Thu, 11 Dec 2025 23:16:22 +0000 (08:16 +0900)]
phy: mediatek: phy-mtk-hdmi-mt8195: convert from round_rate() to determine_rate()
The round_rate() clk ops is deprecated, so migrate this driver from
round_rate() to determine_rate() using the Coccinelle semantic patch
on the cover letter of this series.
Brian Masney [Thu, 11 Dec 2025 23:16:21 +0000 (08:16 +0900)]
phy: mediatek: phy-mtk-hdmi-mt8173: convert from round_rate() to determine_rate()
The round_rate() clk ops is deprecated, so migrate this driver from
round_rate() to determine_rate() using the Coccinelle semantic patch
on the cover letter of this series.
Brian Masney [Thu, 11 Dec 2025 23:16:20 +0000 (08:16 +0900)]
phy: mediatek: phy-mtk-hdmi-mt2701: convert from round_rate() to determine_rate()
The round_rate() clk ops is deprecated, so migrate this driver from
round_rate() to determine_rate() using the Coccinelle semantic patch
on the cover letter of this series.
Brian Masney [Thu, 11 Dec 2025 23:16:19 +0000 (08:16 +0900)]
phy: freescale: phy-fsl-samsung-hdmi: convert from round_rate() to determine_rate()
The round_rate() clk ops is deprecated, so migrate this driver from
round_rate() to determine_rate() using the Coccinelle semantic patch
on the cover letter of this series.
Add squelch detect parameter update for synopsys eusb2 repeater. The
values (indicated in basis-points) depict a percentage change with
respect to the nominal value.
Chukun Pan [Wed, 10 Sep 2025 12:20:00 +0000 (20:20 +0800)]
phy: rockchip: naneng-combphy: use existing DT property check for rk3528
The naneng-combphy driver already has DT property checks for
"rockchip,enable-ssc" and "rockchip,ext-refclk", use it for
the rk3528_combphy_cfg. Also aligned the indentation of the
rk3528_combphy_grfcfgs parameters (using tabs).
Abel Vesa [Tue, 9 Dec 2025 23:09:45 +0000 (15:09 -0800)]
phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms
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.
Add the necessary PHY setting tables for enabling the DP path within the
QMP subsystem. Introduced some new callbacks for v8 specific sequences,
such as for clock configurations based on the different link speeds.
Wesley Cheng added some updated settings from the hardware programming
guides on existing PHY tables and clock settings.
Wesley Cheng [Tue, 9 Dec 2025 23:09:44 +0000 (15:09 -0800)]
phy: qualcomm: qmp-combo: Update QMP PHY with Glymur settings
For SuperSpeed USB to work properly, there is a set of HW settings that
need to be programmed into the USB blocks within the QMP PHY. Ensure that
these settings follow the latest settings mentioned in the HW programming
guide. The QMP USB PHY on Glymur is a USB43 based PHY that will have some
new ways to define certain registers, such as the replacement of TXA/RXA
and TXB/RXB register sets. This was replaced with the LALB register set.
There are also some PHY init updates to modify the PCS MISC register space.
Without these, the QMP PHY PLL locking fails.
Wesley Cheng [Tue, 9 Dec 2025 23:09:42 +0000 (15:09 -0800)]
phy: qualcomm: qmp-usb: Add support for Glymur USB UNI PHY
Glymur contains a USB multiport controller which supports a QMP UNI PHY.
These ports do not have typeC capability, so it needs to be differentiated
in this manner. Update the QMP PHY sequence required to bring up the UNI
PHY for Glymur. The UNI PHY follows mostly the same register field
definitions as previous SoCs.
Wesley Cheng [Tue, 9 Dec 2025 23:09:41 +0000 (15:09 -0800)]
phy: qualcomm: eusb2-repeater: Add SMB2370 eUSB2 repeater support
Introduce support for the SMB2370 based eUSB2 repeater. Configure the
proper repeater tuning settings, as if this is not done correctly, it
can lead to instability on the USB2 link, which leads to USB2
enumeration failures, or random disconnects.
Wesley Cheng [Tue, 9 Dec 2025 23:09:38 +0000 (15:09 -0800)]
dt-bindings: phy: qcom,qmp-usb: Add Glymur USB UNI PHY compatible
The Glymur USB subsystem contains a multiport controller, which utilizes
two QMP UNI PHYs. Add the proper compatible string for the Glymur SoC, and
the required clkref clock name.
Vladimir Oltean [Tue, 25 Nov 2025 11:48:47 +0000 (13:48 +0200)]
phy: lynx-28g: improve lynx_28g_probe() sequence
dev_set_drvdata() is called twice, it is sufficient to do it only once.
devm_of_phy_provider_register() can fail, and if it does, the
&priv->cdr_check work item is queued, but not cancelled, and the device
probing failed, so it will trigger use after free. This is a minor risk
though.
Resource initialization should be done a little earlier, in case we need
to dereference dev_get_drvdata() in lynx_28g_pll_read_configuration() or
in lynx_28g_lane_read_configuration().
Ioana Ciornei [Tue, 25 Nov 2025 11:48:45 +0000 (13:48 +0200)]
phy: lynx-28g: configure more equalization params for 1GbE and 10GbE
While adding support for 25GbE, it was noticed that the RCCR0 and TTLCR0
registers have different values for this protocol than the 10GbE and
1GbE modes.
Expand the lynx_28g_proto_conf[] array with the expected values for the
currently supported protocols. These were dumped from a live system, and
are the out-of-reset values. It will ensure that the lane is configured
with these values when transitioning from 25GbE back into one of these
modes.
Vladimir Oltean [Tue, 25 Nov 2025 11:48:44 +0000 (13:48 +0200)]
phy: lynx-28g: distinguish between 10GBASE-R and USXGMII
The driver does not handle well protocol switching to or from USXGMII,
because it conflates it with 10GBase-R.
In the expected USXGMII use case, that isn't a problem, because SerDes
protocol switching performed by the lynx-28g driver is not necessary,
because USXGMII natively supports multiple speeds, as opposed to SFP
modules using 1000Base-X or 10GBase-R which require switching between
the 2.
That being said, let's be explicit, and in case someone requests a
protocol change which involves USXGMII, let's do the right thing.
Vladimir Oltean [Tue, 25 Nov 2025 11:48:43 +0000 (13:48 +0200)]
phy: lynx-28g: refactor lane->interface to lane->mode
Lynx 28G is a multi-protocol SerDes - it handles serial Ethernet, PCIe,
SATA.
The driver should not use the phylib-specific phy_interface_t as an
internal data representation, but something specific to its internal
capabilities, and only convert to phy_interface_t when PHY_MODE_ETHERNET
is selected and used.
Otherwise it has no way of representing the non-Ethernet lanes (which
was not a short-term goal when the driver was introduced, and is not a
goal per se right now either, but should nonetheless be possible).
Prefer the "enum lynx_lane_mode" name over "lynx_28g_lane_mode", in
preparation of future Lynx 10G SerDes support. This SerDes is part of
the same IP family and has similar capabilities, and will reuse some
code, hence the common data type.
Vladimir Oltean [Tue, 25 Nov 2025 11:48:42 +0000 (13:48 +0200)]
phy: lynx-28g: make lynx_28g_set_lane_mode() more systematic
The current approach of transitioning from one SerDes protocol to
another in lynx_28g_set_lane_mode() is too poetic.
Because the driver only supports 1GbE and 10GbE, it only modifies those
registers which it knows are different between these two modes. However,
that is hardly extensible for 25GbE, 40GbE, backplane modes, etc.
We need something more systematic to make sure that all lane and
protocol converter registers are written to consistent values, no matter
what was the source lane mode.
For that, we need to introduce tables with register field values, for
each supported lane mode.
Eliminate the need to calculate a lane_offset manually, and generate
some macros which access the protocol converter corresponding to the
correct lane in the PCC* registers.
Vladimir Oltean [Tue, 25 Nov 2025 11:48:40 +0000 (13:48 +0200)]
phy: lynx-28g: convert iowrite32() calls with magic values to macros
The driver will need to become more careful with the values it writes to
the TX and RX equalization registers. As a preliminary step, convert the
magic numbers to macros defining the register field meanings.
Vladimir Oltean [Tue, 25 Nov 2025 11:48:39 +0000 (13:48 +0200)]
phy: lynx-28g: use FIELD_GET() and FIELD_PREP()
Reduce the number of bit field definitions required in this driver (in
the worst case, a read form and a write form), by defining just the
mask, and using the FIELD_GET() and FIELD_PREP() API from
<linux/bitfield.h> with that.
projects / thirdparty / linux.git / log
