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.
Vladimir Oltean [Tue, 25 Nov 2025 11:48:38 +0000 (13:48 +0200)]
phy: lynx-28g: don't concatenate lynx_28g_lane_rmw() argument "reg" with "val" and "mask"
The last step in having lynx_28g_lane_rmw() arguments that fully point
to their definitions is the removal of the current concatenation logic,
by which e.g. "LNaTGCR0, N_RATE_QUARTER, N_RATE_MSK" is expanded to
"LNaTGCR0, LNaTGCR0_N_RATE_QUARTER, LNaTGCR0_N_RATE_MSK".
There are pros and cons to the above. An advantage is the impossibility
to mix up fields of one register with fields of another. For example
both LNaTGCR0 and LNaRGCR0 contain an N_RATE_QUARTER field (one for the
lane RX direction, one for the lane TX).
But the two notable disadvantages are:
1. the impossibility to write expressions such as logical OR between
multiple fields. Practically, this forces us to perform more accesses
to hardware registers than would otherwise be needed. See the LNaGCR0
access for example.
2. the necessity to invent fields that don't exist, like SGMIIaCR1_SGPCS_DIS,
in order to clear SGMIIaCR1_SGPCS_EN (the real field name). This is
confusing, because sometimes, fields that end with _DIS really exist,
and it's best to not invent new field names.
Vladimir Oltean [Tue, 25 Nov 2025 11:48:37 +0000 (13:48 +0200)]
phy: lynx-28g: remove LYNX_28G_ prefix from register names
Currently, in macros such as lynx_28g_lane_rmw(), the driver has
macros which concatenate the LYNX_28G_ prefix with the "val" and "mask"
arguments. This is done to shorten function calls and not have to spell
out LYNX_28G_ everywhere.
But outside of lynx_28g_lane_rmw(), lynx_28g_lane_read() and
lynx_28g_pll_read(), this is not done, leading to an inconsistency in
the code.
Also, the concatenation itself has the disadvantage that searching the
arguments of these functions as full words (like N_RATE_QUARTER) leads
us nowhere, since the real macro definition is LNaTGCR0_N_RATE_QUARTER.
Some maintainers want register definitions in drivers to contain the
driver name as a prefix, but here, this has the disadvantages listed
above, so just remove that prefix.
The only change made here is the removal of LYNX_28G_.
Vladimir Oltean [Tue, 25 Nov 2025 11:48:36 +0000 (13:48 +0200)]
phy: lynx-28g: avoid memsetting lane already allocated with kzalloc()
"priv" is allocated by lynx_28g_probe() using devm_kzalloc(), and the
lane is memory inside that structure (&priv->lane[id]). We don't have to
zero-initialize it, it is already filled with zeroes.
Vladimir Oltean [Tue, 25 Nov 2025 11:48:35 +0000 (13:48 +0200)]
phy: lynx-28g: support individual lanes as OF PHY providers
Currently, the bindings of this multi-lane SerDes are such that
consumers specify the lane index in the PHY cell, and the lane itself is
not described in the device tree.
It is desirable to describe individual Lynx 28G SerDes lanes in the
device tree, in order to be able to customize electrical properties such
as those in Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
(or others).
If each lane may have an OF node, it appears natural for consumers to
have their "phys" phandle point to that OF node.
The problem is that transitioning between one format and another is a
breaking change. The bindings of the 28G Lynx SerDes can themselves be
extended in a backward-compatible way, but the consumers cannot be
modified without breaking them.
Namely, if we have:
&mac {
phys = <&serdes1 0>;
};
we cannot update the device tree to:
&mac {
phys = <&serdes1_lane_0>;
};
because old kernels cannot resolve this phandle to a valid PHY.
The proposal here is to keep tolerating existing device trees, which are
not supposed to be changed, but modify lynx_28g_xlate() to also resolve
the new format with #phy-cells = <0> in the lanes.
This way we support 3 modes:
- Legacy device trees, no OF nodes for lanes
- New device trees, OF nodes for lanes and "phys" phandle points towards
them
- Hybrid device trees, OF nodes for lanes (to describe electrical
parameters), but "phys" phandle points towards the SerDes top-level
provider
Vladimir Oltean [Tue, 25 Nov 2025 11:48:33 +0000 (13:48 +0200)]
dt-bindings: phy: lynx-28g: permit lane OF PHY providers
Josua Mayer requested to have OF nodes for each lane, so that he
(and other board developers) can further describe electrical parameters
individually.
For this use case, we need a container node to apply the already
existing Documentation/devicetree/bindings/phy/transmit-amplitude.yaml,
plus whatever other schemas might get standardized for TX equalization
parameters, polarity inversion etc.
When lane OF nodes exist, these are also PHY providers ("phys" phandles
can point directly to them). Compare that to the existing binding, where
the PHY provider is the top-level SerDes node, and the second cell in
the "phys" phandle specifies the lane index.
The new binding format overlaps over the old one without interfering,
but there is a caveat:
Existing device trees, which already have "phys = <&serdes1 0>" cannot
be converted to "phys = <&serdes_1_lane_a>", because in doing so, we
would break compatibility with old kernels which don't understand how to
translate the latter phandle to a PHY.
The transition to the new phandle format can be performed only after a
reasonable amount of time has elapsed after this schema change and the
corresponding driver change have been backported to stable kernels.
However, the aforementioned transition is not strictly necessary, and
the "hybrid" description (where individual lanes have their own OF node,
but are not pointed to by the "phys" phandle) can remain for an
indefinite amount of time, even if a little inelegant.
For newly introduced device trees, where there are no compatibility
concerns with old kernels to speak of, it is strongly recommended to use
the "phys = <&serdes_1_lane_a>" format. The same holds for phandles
towards lanes of LX2160A SerDes #3, which at the time of writing is not
yet described in fsl-lx2160a.dtsi, so there is no legacy to maintain.
To avoid the strange situation where we have a "phy" (SerDes node) ->
"phy" (lane node) hierarchy, let's rename the expected name of the
top-level node to "serdes", and update the example too. This has a
theoretical chance of causing regressions if bootloaders search for
hardcoded paths rather than using aliases, but to the best of my
knowledge, for LX2160A/LX2162A this is not the case.
phy: exynos5-usbdrd: support SS combo phy for ExynosAutov920
Update phy driver to enable SS combo phy for this SoC. New registers'
definitions, phy ops (init/exit), and dedicated phy driver data
structure are added for SS combo phy. Add these changes in the driver
to support SS combo phy for this SoC.
The USBDRD31 5nm controller consists of Synopsys USB20 femptoPhy and
USB31 SSP+ combophy. Document support for the USB31 SSP+ phy found on
combophy of the ExynosAutov920 SoC.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Pritam Manohar Sutar <pritam.sutar@samsung.com> Link: https://patch.msgid.link/20251124110453.2887437-6-pritam.sutar@samsung.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
phy: exynos5-usbdrd: support HS combo phy for ExynosAutov920
Support UTMI+ combo phy for this SoC, which is somewhat similar to
what the existing Exynos850 supports. The difference is that some
register offsets and bit fields are different from Exynos850.
Add required change in phy driver to support combo HS phy for this SoC.
The USBDRD31 5nm controller consists of Synopsys USB2.0 femptophy and
USBSS combophy. Add-on USB20 femptophy is required to support USB20 data
rates along with USBSS phy. Document support for the USB2.0 femptophy
found on combophy of the this SoC.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Pritam Manohar Sutar <pritam.sutar@samsung.com> Link: https://patch.msgid.link/20251124110453.2887437-4-pritam.sutar@samsung.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Document support for the USB20 phy found on the ExynosAutov920 SoC. The
USB20 phy is functionally identical to that on the Exynos850 SoC, so no
driver changes are needed to support this phy. However, add a dedicated
compatible string for USB20 phy found in this SoC.
This phy needs 0.75v, 0.18v and 3.3v supplies for its internal
functionally. Power Supply's names are as per phy's User Data-Book.
These names, (dvdd, vdd18 and vdd33), are considered for 0.75v, 1.8v
and 3.3v respectively.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Pritam Manohar Sutar <pritam.sutar@samsung.com> Link: https://patch.msgid.link/20251124110453.2887437-2-pritam.sutar@samsung.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Sven Peter [Sun, 14 Dec 2025 11:51:36 +0000 (11:51 +0000)]
phy: apple: Add Apple Type-C PHY
The Apple Type-C PHY (ATCPHY) is a PHY for USB 2.0, USB 3.x,
USB4/Thunderbolt, and DisplayPort connectivity found in Apple Silicon SoCs.
The PHY handles muxing between these different protocols and also provides
the reset controller for the attached dwc3 USB controller.
There is no documentation available for this PHY and the entire sequence
of MMIO pokes has been figured out by tracing all MMIO access of Apple's
driver under a thin hypervisor and correlating the register reads/writes
to their kernel's debug output to find their names. Deviations from this
sequence generally results in the port not working or, especially when
the mode is switched to USB4 or Thunderbolt, to some watchdog resetting
the entire SoC.
This initial commit already introduces support for Display Port and
USB4/Thunderbolt but the drivers for these are not ready. We cannot
control the alternate mode negotiation and are stuck with whatever Apple's
firmware decides such that any DisplayPort or USB4/Thunderbolt device will
result in a correctly setup PHY but not be usable until the other drivers
are upstreamed as well.
Co-developed-by: Janne Grunau <j@jannau.net> Signed-off-by: Janne Grunau <j@jannau.net> Co-developed-by: Hector Martin <marcan@marcan.st> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> # for reset controller Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://patch.msgid.link/20251214-b4-atcphy-v3-3-ba82b20e9459@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
Sven Peter [Sun, 14 Dec 2025 11:51:34 +0000 (11:51 +0000)]
soc: apple: Add hardware tunable support
Various hardware, like the Type-C PHY or the Thunderbolt/USB4 NHI,
present on Apple SoCs need machine-specific tunables passed from our
bootloader m1n1 to the device tree. Add generic helpers so that we
don't have to duplicate this across multiple drivers.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Janne Grunau <j@jannau.net> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://patch.msgid.link/20251214-b4-atcphy-v3-1-ba82b20e9459@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
Xiangxu Yin [Mon, 15 Dec 2025 12:42:08 +0000 (20:42 +0800)]
phy: qcom: qmp-usbc: Add QCS615 USB/DP PHY config and DP mode support
Add QCS615-specific configuration for USB/DP PHY, including DP init
routines, voltage swing tables, and platform data. Add compatible
"qcs615-qmp-usb3-dp-phy".
Note: SW_PORTSELECT handling for orientation flip is not implemented
due to QCS615 fixed-orientation design and non-standard lane mapping.
Xiangxu Yin [Mon, 15 Dec 2025 12:42:06 +0000 (20:42 +0800)]
phy: qcom: qmp-usbc: Add USB/DP exclude handling
When both USB and DP PHY modes are enabled simultaneously on the same
QMP USBC PHY, it can lead to hardware misconfiguration and undefined
behavior. This happens because the PHY resources are not designed to
operate in both modes at the same time.
To prevent this, introduce a mutual exclusion check between USB and DP
PHY modes.
Xiangxu Yin [Mon, 15 Dec 2025 12:42:03 +0000 (20:42 +0800)]
phy: qcom: qmp-usbc: Move USB-only init to usb_power_on
The current implementation programs USB-specific registers in
qmp_usbc_com_init(), which is shared by both USB and DP modes. This
causes unnecessary configuration when the PHY is used for DP.
Move USB-only register setup from com_init to qmp_usbc_usb_power_on,
so it runs only for USB mode.
Xiangxu Yin [Mon, 15 Dec 2025 12:42:02 +0000 (20:42 +0800)]
phy: qcom: qmp-usbc: add DP link and vco_div clocks for DP PHY
USB3DP PHY requires link and vco_div clocks when operating in DP mode.
Extend qmp_usbc_register_clocks and the clock provider logic to register
these clocks along with the existing pipe clock, to support both USB and
DP configurations.
Xiangxu Yin [Mon, 15 Dec 2025 12:42:01 +0000 (20:42 +0800)]
phy: qcom: qmp-usbc: Move reset config into PHY cfg
The original reset list only works for USB-only PHYs. USB3DP PHYs require
different reset names such as "dp_phy", so they need a separate list.
Moving reset configuration into qmp_phy_cfg allows per-PHY customization
without adding special-case logic in DT parsing. The legacy DT path keeps
using the old hardcoded list, while non-legacy paths use cfg->reset_list.
Xiangxu Yin [Mon, 15 Dec 2025 12:42:00 +0000 (20:42 +0800)]
phy: qcom: qmp-usbc: Add regulator init_load support
QMP USBC PHY drivers previously did not set init_load_uA for regulators,
which could result in incorrect vote levels. This patch introduces
regulator definitions with proper init_load_uA values based on each
chip's power grid design.
QCS615 USB3 PHY was previously reusing qcm2290_usb3phy_cfg, but its
regulator requirements differ. A new qcs615_usb3phy_cfg is added to
reflect the correct settings.
Xiangxu Yin [Mon, 15 Dec 2025 12:41:59 +0000 (20:41 +0800)]
phy: qcom: qmp-usbc: Add DP-related fields for USB/DP switchable PHY
Extend qmp_usbc_offsets and qmp_phy_cfg with DP-specific fields,
including register offsets, init tables, and callback hooks. Also
update qmp_usbc struct to track DP-related resources and state.
This enables support for USB/DP switchable Type-C PHYs that operate
in either mode.
Xiangxu Yin [Mon, 15 Dec 2025 12:41:58 +0000 (20:41 +0800)]
phy: qcom: qmp-usbc: Rename USB-specific ops to prepare for DP support
To support following DisplayPort (DP) mode over the Type-C PHY, rename
USB-specific functions and ops to clearly separate them from common or
DP-related logic.
This is a preparatory cleanup to enable USB + DP dual mode.
Xiangxu Yin [Mon, 15 Dec 2025 12:41:57 +0000 (20:41 +0800)]
dt-bindings: phy: Add QMP USB3+DP PHY for QCS615
Add device tree binding documentation for the Qualcomm QMP USB3+DP PHY
on QCS615 Platform. This PHY supports both USB3 and DP functionality
over USB-C, with PHY mode switching capability. It does not support
combo mode.
Lad Prabhakar [Tue, 9 Dec 2025 16:21:19 +0000 (16:21 +0000)]
dt-bindings: phy: ti,tcan104x-can: Document TI TCAN1046
Document the TI TCAN1046 automotive CAN transceiver. The TCAN1046 is a
dual high-speed CAN transceiver with sleep-mode support and no EN pin,
mirroring the behaviour of the NXP TJA1048, which also provides dual
channels and STB1/2 sleep-control lines.
phy: qcom-qmp-usb: Set regulator load before enabling
Set the regulator load before enabling the regulators to ensure stable
operation and proper power management on platforms where regulators are
shared between the QMP USB PHY and other IP blocks.
Introduce a regulator data structure with explicit enable load values and
use the regulator framework's `init_load_uA` field along with
`devm_regulator_bulk_get_const()` to ensure that `regulator_set_load()` is
applied automatically before the first enable, providing consistent power
management behavior across platforms.
Qiang Yu [Mon, 24 Nov 2025 10:24:37 +0000 (02:24 -0800)]
phy: qcom-qmp: qserdes-com: Add some more v8 register offsets
Some qserdes-com register offsets for the v8 PHY were previously omitted,
as they were not needed by earlier v8 PHY initialization sequences. Add
these missing v8 register offsets now required to support PCIe QMP PHY on
Kaanapali platform.
Kaanapali SoC uses QMP PHY with version v8 for PCIe Gen3 x2, but requires
a completely unique qserdes-txrx register offsets compared to existing v8
offsets.
Hence, add a dedicated header file containing the FULL SET of qserdes-txrx
register definitions required for Kaanapali's PCIe PHY operation.
Alex Elder [Thu, 18 Dec 2025 15:12:29 +0000 (09:12 -0600)]
phy: spacemit: Introduce PCIe/combo PHY
Introduce a driver that supports three PHYs found on the SpacemiT
K1 SoC. The first PHY is a combo PHY that can be configured for
use for either USB 3 or PCIe. The other two PHYs support PCIe
only.
All three PHYs must be programmed with an 8 bit receiver termination
value, which must be determined dynamically. Only the combo PHY is
able to determine this value. The combo PHY performs a special
calibration step at probe time to discover this, and that value is
used to program each PHY that operates in PCIe mode. The combo
PHY must therefore be probed before either of the PCIe-only PHYs
will be used.
Each PHY has an internal PLL driven from an external oscillator.
This PLL started when the PHY is first initialized, and stays
on thereafter.
During normal operation, the USB or PCIe driver using the PHY must
ensure (other) clocks and resets are set up properly.
However PCIe mode clocks are enabled and resets are de-asserted
temporarily by this driver to perform the calibration step on the
combo PHY.
Alex Elder [Thu, 18 Dec 2025 15:12:28 +0000 (09:12 -0600)]
dt-bindings: phy: spacemit: Introduce PCIe PHY
Add the Device Tree binding for two PCIe PHYs present on the SpacemiT
K1 SoC. These PHYs are dependent on a separate combo PHY, which
determines at probe time the calibration values used by the PCIe-only
PHYs.
Add the Device Tree binding for the PCIe/USB 3.0 combo PHY found in
the SpacemiT K1 SoC. This is one of three PCIe PHYs, and is unusual
in that only the combo PHY can perform a calibration step needed to
determine settings used by the other two PCIe PHYs.
Calibration must be done with the combo PHY in PCIe mode, and to allow
this to occur independent of the eventual use for the PHY (PCIe or USB)
some PCIe-related properties must be supplied: clocks; resets; and a
syscon phandle.
dt-bindings: phy: mediatek,hdmi-phy: Fix clock output names for MT8195
For all of the HDMI PHYs compatible with the one found on MT8195
the output clock has a different datasheet name and specifically
it is called "hdmi_txpll", differently from the older HDMI PHYs
which output block is called "hdmitx_dig_cts".
Replace clock output name string check by max item number one to allow
the new name on all of the HDMI PHY IPs that are perfectly compatible
with MT8195.
[Louis-Alexis Eyraud: split patch, addressed previous feedback from
mailing list, and reworded description]
Fixes: c78fe548b062 ("dt-bindings: phy: mediatek: hdmi-phy: Add mt8195 compatible") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patch.msgid.link/20251217-mtk-genio-evk-hdmi-support-v2-1-a994976bb39a@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Attempting to make use of a 1080p@120Hz display mode with 10 bpc RGB on
my Acer XV275K P3 monitor results in a blank image. A similar behavior
has been reported on Philips 279M1RV.
The faulty modeline is created by drm_gtf_mode_complex() based on the
following EDID entry from the Standard Timings block:
It's worth noting the computed pixel clock ends up being slightly higher
at 368.881000 MHz. Nevertheless, this seems to work consistently fine
with 8 bpc RGB.
After switching to 10 bpc, the TMDS character rate expected for the mode
increases to 461.101250 MHz, as per drm_hdmi_compute_mode_clock().
Since there is no entry for this rate in the ropll_tmds_cfg table, the
necessary HDMI PLL configuration parameters are calculated dynamically
by rk_hdptx_phy_clk_pll_calc(). However, the resulting output rate is
not quite a perfect match, i.e. 461.100000 MHz. That proved to be the
actual root cause of the problem.
Add a new entry to the TMDS configuration table and provide the
necessary frequency division coefficients for the PHY PLL to generate
the expected 461.101250 MHz output.
Xu Yang [Fri, 19 Dec 2025 08:13:54 +0000 (16:13 +0800)]
phy: fsl-imx8mq-usb: change ssc_range value for i.MX8MQ
According to IC engineer suggestion, set ssc_range as -4003 ppm
will have more tolerance for EMI, and suitable for more boards.
Besides, it's confirmed that with this setting the TX SSC test
will pass on one customer board.
projects / thirdparty / linux.git / log
