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.
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.
phy: rockchip-samsung-dcphy: Discard pm_runtime_put() return value
Passing pm_runtime_put() return value to the callers is not particularly
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. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update samsung_mipi_dcphy_exit() to simply discard the
return value of pm_runtime_put() and always return success to the
caller.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
phy: freescale: Discard pm_runtime_put() return value
Printing error messages on pm_runtime_put() returning negative values
is not particularly 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.
Accordingly, update mixel_lvds_phy_reset() to simply discard the return
value of pm_runtime_put().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Lad Prabhakar [Mon, 22 Dec 2025 16:18:46 +0000 (16:18 +0000)]
dt-bindings: phy: renesas,rzg3e-usb3-phy: Add RZ/V2H(P) and RZ/V2N support
Add compatibles for the USB3.0 PHY used in the RZ/V2H(P) and RZ/V2N SoCs.
These SoCs integrate the same USB3 PHY IP block as the RZ/G3E, so the
RZ/G3E compatible is used as a fallback for both.
Linus Torvalds [Sun, 14 Dec 2025 03:35:35 +0000 (15:35 +1200)]
Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"The only core fix is in doc; all the others are in drivers, with the
biggest impacts in libsas being the rollback on error handling and in
ufs coming from a couple of error handling fixes, one causing a crash
if it's activated before scanning and the other fixing W-LUN
resumption"
* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: ufs: qcom: Fix confusing cleanup.h syntax
scsi: libsas: Add rollback handling when an error occurs
scsi: device_handler: Return error pointer in scsi_dh_attached_handler_name()
scsi: ufs: core: Fix a deadlock in the frequency scaling code
scsi: ufs: core: Fix an error handler crash
scsi: Revert "scsi: libsas: Fix exp-attached device scan after probe failure scanned in again after probe failed"
scsi: ufs: core: Fix RPMB link error by reversing Kconfig dependencies
scsi: qla4xxx: Use time conversion macros
scsi: qla2xxx: Enable/disable IRQD_NO_BALANCING during reset
scsi: ipr: Enable/disable IRQD_NO_BALANCING during reset
scsi: imm: Fix use-after-free bug caused by unfinished delayed work
scsi: target: sbp: Remove KMSG_COMPONENT macro
scsi: core: Correct documentation for scsi_device_quiesce()
scsi: mpi3mr: Prevent duplicate SAS/SATA device entries in channel 1
scsi: target: Reset t_task_cdb pointer in error case
scsi: ufs: core: Fix EH failure after W-LUN resume error
Linus Torvalds [Sun, 14 Dec 2025 03:24:10 +0000 (15:24 +1200)]
Merge tag 'ceph-for-6.19-rc1' of https://github.com/ceph/ceph-client
Pull ceph updates from Ilya Dryomov:
"We have a patch that adds an initial set of tracepoints to the MDS
client from Max, a fix that hardens osdmap parsing code from myself
(marked for stable) and a few assorted fixups"
* tag 'ceph-for-6.19-rc1' of https://github.com/ceph/ceph-client:
rbd: stop selecting CRC32, CRYPTO, and CRYPTO_AES
ceph: stop selecting CRC32, CRYPTO, and CRYPTO_AES
libceph: make decode_pool() more resilient against corrupted osdmaps
libceph: Amend checking to fix `make W=1` build breakage
ceph: Amend checking to fix `make W=1` build breakage
ceph: add trace points to the MDS client
libceph: fix log output race condition in OSD client
Linus Torvalds [Sat, 13 Dec 2025 18:12:46 +0000 (06:12 +1200)]
Merge tag 'smp-urgent-2025-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull CPU hotplug fix from Ingo Molnar:
- Fix CPU hotplug callbacks to disable interrupts on UP kernels
* tag 'smp-urgent-2025-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
cpu: Make atomic hotplug callbacks run with interrupts disabled on UP
Linus Torvalds [Sat, 13 Dec 2025 18:10:35 +0000 (06:10 +1200)]
Merge tag 'perf-urgent-2025-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf event fixes from Ingo Molnar:
- Fix NULL pointer dereference crash in the Intel PMU driver
- Fix missing read event generation on task exit
- Fix AMD uncore driver init error handling
- Fix whitespace noise
* tag 'perf-urgent-2025-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()
perf/core: Fix missing read event generation on task exit
perf/x86/amd/uncore: Fix the return value of amd_uncore_df_event_init() on error
perf/uprobes: Remove <space><Tab> whitespace noise
Linus Torvalds [Sat, 13 Dec 2025 18:07:09 +0000 (06:07 +1200)]
Merge tag 'irq-urgent-2025-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Ingo Molnar:
- Fix error code in the irqchip/mchp-eic driver
- Fix setup_percpu_irq() affinity assumptions
- Remove the unused irq_domain_add_tree() function
* tag 'irq-urgent-2025-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()
irqdomain: Delete irq_domain_add_tree()
genirq: Allow NULL affinity for setup_percpu_irq()
projects / thirdparty / linux.git / log
