- New Support
- Qualcomm SM8750 QMP PCIe PHY dual lane support, PMIV0104 eusb2 repeater
support, QCS8300 eDP PHY support
- Renesas RZ/T2H and RZ/N2H support and updates to driver for that
- TI TCAN1051 phy support
- Rockchip rk3588 dphy support, RK3528 combphy support
- Updates
- cadence updates for calibration and polling for ready and enabling of
lower resolutions, runtime pm support,
- Rockchip: enable U3 otg port
- Renesas USXGMII mode support
- Qualcomm UFS PHY and PLL regulator load support
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE+vs47OPLdNbVcHzyfBQHDyUjg0cFAmjjbZMACgkQfBQHDyUj
g0cTtBAAqF+dgYsDWkwRLIDbfLxgN2siw3h21tllzy8QfId9K5wjG5plz4u2Zk9/
MkD5gZgdNTkvViFH5iIIV2IgrzeX4E1ed+1SGLcf9wOKUKxgt4j6CxRBvhfWtgQv
pRLpmzOzt+EM4l2G8I8LVtb0fwy7s9ZjvLUVhLnG5b0PCdK+2ozs0vcAr3RLqFWu
xfy3AeaIX5wEop4HeAU/4ofAl2Rmni7i7Cx4V4iy8jThQEjWz7Hyff8tXAYqHJrF
pPInbHU/EFAaiFHJBv/dgDle826jCbuNwy2lD4OxDq8AH4XDAVcBndg4c0lXIGnB
e39FnNSavTVZhbo+zifvBzRd9wEj/ZIv9Lz8RpvJxKl17PTWzRjS0Bhhf4LwRDyR
oso8DlLcB4E12d8EwCrqXkRyRZE5IBRdTF6hgmxJa+50S2h9E/A3qWmJur/U1kCm
meGuodwFZzExjYNqmc0HSAyy5RYnS6P5PGl9D7SxY8QhuFMfpHws9bGaLTpEwwA3
vUsja74qux0Lq/aFX/EuOOdjPQ8E5HOSqhRFoBbQ1drp02TmvVltbwrujWpdOI1n
uwlUi0USu59HQuDUgaeOTL4PH6WYQpDYk8rAqV+Vy96BcvgFYEEXyotZ22XqbxS8
NprtGnU+w0wwIEVv5K7SR6r+RmB/ViEOYEg418GrQCxGIbbOwqs=
=UiHw
-----END PGP SIGNATURE-----
Merge tag 'phy-for-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy
Pull phy updates from Vinod Koul:
"The usual bunch of device support and update to drivers.
New Support
- Qualcomm SM8750 QMP PCIe PHY dual lane support, PMIV0104 eusb2
repeater support, QCS8300 eDP PHY support
- Renesas RZ/T2H and RZ/N2H support and updates to driver for that
- TI TCAN1051 phy support
- Rockchip rk3588 dphy support, RK3528 combphy support
Updates:
- cadence updates for calibration and polling for ready and enabling
of lower resolutions, runtime pm support,
- Rockchip: enable U3 otg port
- Renesas USXGMII mode support
- Qualcomm UFS PHY and PLL regulator load support"
* tag 'phy-for-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (64 commits)
phy: rockchip: phy-rockchip-inno-csidphy: add support for rk3588 variant
phy: rockchip: phy-rockchip-inno-csidphy: allow for different reset lines
phy: rockchip: phy-rockchip-inno-csidphy: allow writes to grf register 0
dt-bindings: phy: rockchip-inno-csi-dphy: add rk3588 variant
dt-bindings: phy: rockchip-inno-csi-dphy: make power-domains non-required
phy: cadence: cdns-dphy: Enable lower resolutions in dphy
phy: renesas: r8a779f0-ether-serdes: add new step added to latest datasheet
phy: renesas: r8a779f0-ether-serdes: add USXGMII mode
phy: sophgo: Add USB 2.0 PHY driver for Sophgo CV18XX/SG200X
dt-bindings: phy: Add Sophgo CV1800 USB phy
phy: cadence: cdns-dphy: Update calibration wait time for startup state machine
phy: cadence: cdns-dphy: Fix PLL lock and O_CMN_READY polling
phy: renesas: rcar-gen3-usb2: Fix ID check logic with VBUS valid
dt-bindings: phy: ti,tcan104x-can: Document TI TCAN1051
phy: lynx-28g: check return value when calling lynx_28g_pll_get
phy: qcom: m31-eusb2: Fix the error log while enabling clock
phy: rockchip: usbdp: Remove redundant ternary operators
phy: renesas: rcar-gen3-usb2: Remove redundant ternary operators
phy: hisilicon: Remove redundant ternary operators
phy: qcom-qmp-ufs: Add PHY and PLL regulator load
...
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
The Rockchip PCIe PHY driver, used on the RK3399, has its own definition
of HIWORD_UPDATE.
Remove it, and replace instances of it with hw_bitfield.h's
FIELD_PREP_WM16. To achieve this, some mask defines are reshuffled, as
FIELD_PREP_WM16 uses the mask as both the mask of bits to write and to
derive the shift amount from in order to shift the value.
In order to ensure that the mask is always a constant, the inst->index
shift is performed after the FIELD_PREP_WM16, as this is a runtime
value.
>From this, we gain compile-time error checking, and in my humble opinion
nicer code, as well as a single definition of this macro across the
entire codebase to aid in code comprehension.
Tested on a RK3399 ROCKPro64, where PCIe still works as expected when
accessing an NVMe drive.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
The Rockchip RK3588 MIPI CSI-2 DPHY can be supported using the existing
phy-rockchip-inno-csidphy driver, the notable differences being
- the control bits in the GRF
- the additional reset line
Add support for this variant.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-6-a4f340a7f0cf@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The RK3588 MIPI CSI-2 DPHY variant requires two reset lines. Add support
for different sets of reset lines to the phy-rockchip-inno-csidphy driver
as preparation for the introduction of the RK3588 variant.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-5-a4f340a7f0cf@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The driver for the Rockchip MIPI CSI-2 DPHY uses GRF register offset
value 0 to sort out undefined registers. However, the RK3588 CSIDPHY GRF
this offset is perfectly fine (in fact, register 0 is the only one in
this register file).
Introduce a boolean variable to indicate valid registers and allow writes
to register 0.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-4-a4f340a7f0cf@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Enable support for data lane rates between 80-160 Mbps cdns dphy
as mentioned in TRM [0] by setting the pll_opdiv field to 16.
This change enables lower resolutions like 640x480 at 60Hz.
[0]: https://www.ti.com/lit/zip/spruil1
(Table 12-552. DPHY_TX_PLL_CTRL Register Field Descriptions)
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Harikrishna Shenoy <h-shenoy@ti.com>
Link: https://lore.kernel.org/r/20250807052002.717807-1-h-shenoy@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add USB 2.0 PHY driver for Sophgo CV18XX/SG200X. Currently
this driver does not support OTG mode as lack of document.
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20250708063038.497473-3-inochiama@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Do read-modify-write so that we re-use the characterized reset value as
specified in TRM [1] to program calibration wait time which defines number
of cycles to wait for after startup state machine is in bandgap enable
state.
This fixes PLL lock timeout error faced while using RPi DSI Panel on TI's
AM62L and J721E SoC since earlier calibration wait time was getting
overwritten to zero value thus failing the PLL to lockup and causing
timeout.
[1] AM62P TRM (Section 14.8.6.3.2.1.1 DPHY_TX_DPHYTX_CMN0_CMN_DIG_TBIT2):
Link: https://www.ti.com/lit/pdf/spruj83
Cc: stable@vger.kernel.org
Fixes: 7a343c8bf4 ("phy: Add Cadence D-PHY support")
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Tested-by: Harikrishna Shenoy <h-shenoy@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://lore.kernel.org/r/20250704125915.1224738-3-devarsht@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
PLL lockup and O_CMN_READY assertion can only happen after common state
machine gets enabled by programming DPHY_CMN_SSM register, but driver was
polling them before the common state machine was enabled which is
incorrect. This is as per the DPHY initialization sequence as mentioned in
J721E TRM [1] at section "12.7.2.4.1.2.1 Start-up Sequence Timing Diagram".
It shows O_CMN_READY polling at the end after common configuration pin
setup where the common configuration pin setup step enables state machine
as referenced in "Table 12-1533. Common Configuration-Related Setup
mentions state machine"
To fix this :
- Add new function callbacks for polling on PLL lock and O_CMN_READY
assertion.
- As state machine and clocks get enabled in power_on callback only, move
the clock related programming part from configure callback to power_on
callback and poll for the PLL lockup and O_CMN_READY assertion after state
machine gets enabled.
- The configure callback only saves the PLL configuration received from the
client driver which will be applied later on in power_on callback.
- Add checks to ensure configure is called before power_on and state
machine is in disabled state before power_on callback is called.
- Disable state machine in power_off so that client driver can re-configure
the PLL by following up a power_off, configure, power_on sequence.
[1]: https://www.ti.com/lit/zip/spruil1
Cc: stable@vger.kernel.org
Fixes: 7a343c8bf4 ("phy: Add Cadence D-PHY support")
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Tested-by: Harikrishna Shenoy <h-shenoy@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://lore.kernel.org/r/20250704125915.1224738-2-devarsht@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Remove this driver's HIWORD_UPDATE macro, and replace all instances of
it with (hopefully) equivalent FIELD_PREP_WM16 instances. To do this, a
few of the defines are being adjusted, as FIELD_PREP_WM16 shifts up the
value for us. This gets rid of the icky update(mask, mask) shenanigans.
The benefit of using FIELD_PREP_WM16 is that it does more checking of
the input, hopefully catching errors. In practice, a shared definition
makes code more readable than several different flavours of the same
macro, and the shifted value helps as well.
I do not have the hardware that uses this particular driver, so it's
compile-tested only as far as my own testing goes.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
phy-rockchip-samsung-dcphy is actually an exemplary example, where the
similarities to FIELD_PREP were spotted and the driver local macro has
the same semantics as the new FIELD_PREP_WM16 hw_bitfield.h macro.
Still, get rid of FIELD_PREP_HIWORD now that a shared implementation
exists, replacing the two instances of it with FIELD_PREP_WM16. This
gives us slightly better error checking; the value is now checked to fit
in 16 bits.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Replace the implementation of the rockchip eMMC PHY driver's
HIWORD_UPDATE macro with hw_bitfield.h's FIELD_PREP_WM16. This makes the
change more easily reviewable.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Commit 0cc22f5a86 ("phy: qcom: qmp-pcie: Add PHY register retention
support") added support for using the "no_csr" reset to skip configuration
of the PHY if the init sequence was already applied by the boot firmware.
The expectation is that the PHY is only turned on/off by using the "no_csr"
reset, instead of powering it down and re-programming it after a full
reset.
The boot firmware on X1E does not fully conform to this expectation: If the
PCIe3 link fails to come up (e.g. because no PCIe card is inserted), the
firmware powers down the PHY using the QPHY_PCS_POWER_DOWN_CONTROL
register. The QPHY_START_CTRL register is kept as-is, so the driver assumes
the PHY is already initialized and skips the configuration/power up
sequence. The PHY won't come up again without clearing the
QPHY_PCS_POWER_DOWN_CONTROL, so eventually initialization fails:
qcom-qmp-pcie-phy 1be0000.phy: phy initialization timed-out
phy phy-1be0000.phy.0: phy poweron failed --> -110
qcom-pcie 1bd0000.pcie: cannot initialize host
qcom-pcie 1bd0000.pcie: probe with driver qcom-pcie failed with error -110
This can be reliably reproduced on the X1E CRD, QCP and Devkit when no card
is inserted for PCIe3.
Fix this by checking the QPHY_PCS_POWER_DOWN_CONTROL register in addition
to QPHY_START_CTRL. If the PHY is powered down with the register, it
doesn't conform to the expectations for using the "no_csr" reset, so we
fully re-initialize with the normal reset sequence.
Also check the register more carefully to ensure all of the bits we expect
are actually set. A simple !!(readl()) is not enough, because the PHY might
be only partially set up with some of the expected bits set.
Cc: stable@vger.kernel.org
Fixes: 0cc22f5a86 ("phy: qcom: qmp-pcie: Add PHY register retention support")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250821-phy-qcom-qmp-pcie-nocsr-fix-v3-1-4898db0cc07c@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The existing ID detection logic returned false when both IDDIG and
VBUSVALID were set, which caused incorrect role determination in some
cases. The condition:
!(device && !vbus_valid)
did not properly reflect the intended relationship between IDDIG and
VBUSVALID signals.
Update the logic to:
return vbus_valid ? device : !device;
This ensures that when VBUS is valid, the role follows the IDDIG value,
and when VBUS is not valid, the role is inverted, matching the expected
OTG behavior.
Fixes: b725741f1c ("phy: renesas: rcar-gen3-usb2: Add support for RZ/T2H SoC")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20250821155957.1088337-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Some SoCs are just validated with the TX delay enabled. With commit
ca13b249f2 ("net: ethernet: ti: am65-cpsw: fixup PHY mode for fixed
RGMII TX delay"), the network driver will patch the delay setting on the
fly assuming that the TX delay setting is fixed. In reality, the TX
delay is configurable and just skipped in the documentation. There are
bootloaders, which will disable the TX delay and this will lead to a
transmit path which doesn't add any delays at all.
Fix that by always writing the RGMII_ID setting and report an error for
unsupported RGMII delay modes.
This is safe to do and shouldn't break any boards in mainline because
the fixed delay is only introduced for gmii-sel compatibles which are
used together with the am65-cpsw-nuss driver and also contains the
commit above.
Fixes: ca13b249f2 ("net: ethernet: ti: am65-cpsw: fixup PHY mode for fixed RGMII TX delay")
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://lore.kernel.org/r/20250819065622.1019537-1-mwalle@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
While enabling clock, we incorrectly log 'ref clk' as 'cfg ahb clk'
Fix this since the devicetree bindings mentions it as ref clock.
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250826105254.3758803-1-prashanth.k@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add phy and pll regulator load voting support for all supported
platforms by introducing dedicated regulator bulk data arrays
with their load values.
This ensures stable operation and proper power management for these
platforms where regulators are shared between the QMP UFS PHY and
other IP blocks by setting appropriate regulator load currents during
PHY operations.
Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://lore.kernel.org/r/20250830070353.2694-3-nitin.rawat@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
On certain SoCs, power regulators are shared between the QMP UFS PHY
and other IP blocks. To ensure proper operation, the regulator
framework must be informed of the UFS PHY's load requirements.
This is essential because the regulator's operating mode—whether Low
Power or High Power—depends on the maximum expected load at any given
time, which the regulator driver needs to manage accordingly.
To support this, replace devm_regulator_bulk_get() with
devm_regulator_bulk_get_const() and inline the qmp_ufs_vreg_init()
function. additionally replace the array of regulator names with a
bulk regulator data structure, and utilize the init_load_uA field
provided by the regulator framework. This ensures that
regulator_set_load() is automatically invoked before the
first enable operation.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
Link: https://lore.kernel.org/r/20250830070353.2694-2-nitin.rawat@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Use core driver model helper dev_err_probe() defined at
drivers/base/core.c in driver probe path to propagate errors.
standardize and improve the code of deferred probe error handling
using this helper for ingenic usb phy driver.
Inspired by,
commit a787e5400a ("driver core: add device probe log helper")
Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Link: https://lore.kernel.org/r/aIIMW971BYsIk4As@bhairav-test.ee.iitb.ac.in
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Relocate the debug print in rcar_gen3_enable_vbus_ctrl() to appear after
the `val` variable is assigned and updated based on the VBUS state. This
ensures that the debug log reflects the actual register value being
written, improving debugging accuracy.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250808215209.3692744-6-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add initial support for the Renesas RZ/T2H SoC to the R-Car Gen3 USB2 PHY
driver. The RZ/T2H SoC requires configuration of additional
hardware-specific bits for proper VBUS level control and OTG operation.
Introduce the `vblvl_ctrl` flag in the SoC-specific driver data to enable
handling of VBUS level selection logic using `VBCTRL.VBLVL` bits. This is
required for managing the VBUS status detection and drive logic based on
SoC-specific needs.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250808215209.3692744-5-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Update the PHY driver to support SoC-specific OBINT enable bits by
introducing the `obint_enable_bits` field in the `rcar_gen3_phy_drv_data`
structure. This allows each SoC to specify bits required.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250808215209.3692744-4-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Store the SoC-specific driver data pointer (struct rcar_gen3_phy_drv_data)
directly in struct rcar_gen3_chan instead of copying individual flags into
separate channel members.
Obtain the drvdata with of_device_get_match_data() in probe and assign it
to channel->phy_data. Update all call sites to reference
`channel->phy_data->*` for SoC-specific behaviour (for example no_adp_ctrl
and utmi_ctrl). Remove the redundant soc_no_adp_ctrl and utmi_ctrl fields
from struct rcar_gen3_chan.
This simplifies the probe path, reduces duplication, and makes it easier
to extend the driver with additional platform-specific fields in the
future.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20250808215209.3692744-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Register a typec mux in order to change the PHY mode on the Type-C
mux events depending on the mode and the svid when in Altmode setup.
The DisplayPort phy should be left enabled if is still powered on
by the DRM DisplayPort controller, so bail out until the DisplayPort
PHY is not powered off.
The Type-C Mode/SVID only changes on plug/unplug, and USB SAFE states
will be set in between of USB-Only, Combo and DisplayPort Only so
this will leave enough time to the DRM DisplayPort controller to
turn of the DisplayPort PHY.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
[konrad: renaming, rewording, bug fixes]
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Lenovo Thinkpad T14S
Link: https://lore.kernel.org/r/20250807-topic-4ln_dp_respin-v4-5-43272d6eca92@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Introduce an enum for the QMP Combo PHY modes, use it in the
QMP commmon phy init function and default to COMBO mode.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
[konrad: some renaming and rewording]
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Lenovo Thinkpad T14S
Link: https://lore.kernel.org/r/20250807-topic-4ln_dp_respin-v4-4-43272d6eca92@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Switching the PHY Mode requires the DisplayPort PHY to be powered off,
keep track of the DisplayPort phy power state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Lenovo Thinkpad T14S
Link: https://lore.kernel.org/r/20250807-topic-4ln_dp_respin-v4-3-43272d6eca92@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
There are a numbers of ""modes"" involved: USB mode, Type-C mode (with
its altmodes), phy_mode and QMP_PHY mode (DP/combo/USB/off).
Rename the generic sounding 'mode' to 'phy_mode' to hopefully make
the code easier to follow.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Lenovo Thinkpad T14S
Link: https://lore.kernel.org/r/20250807-topic-4ln_dp_respin-v4-2-43272d6eca92@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Replace comma between expressions with semicolons.
Using a ',' in place of a ';' can have unintended side effects.
Although that is not the case here, it is seems best to use ';'
unless ',' is intended.
Found by inspection.
No functional change intended.
Compile tested only.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://lore.kernel.org/r/20250814013943.2905307-1-nichen@iscas.ac.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org>
So far we set a number of expected Allwinner USB PHY instances for any
given compatible string, and would fail if we do not find every PHY
described properly in the DT (missing reset/PMU/clocks).
This is somewhat redundant, as the DT only describes the resources for
the implemented PHYs, but goes in line with being strict about firmware
descriptions, and rather fixing things in the driver code, based on the
compatible string.
However this causes issues when we make a mistake, like we did recently
on the A523: there are actually three USB PHYs, not two, as we assumed.
Changing the number in the driver and the compatible string would cause
all kinds of compatibility issues, both with older and newer DTs.
To avoid problems with newer kernels and older or newer DTs, we can change
the driver code to deduce the number of PHY instances from what's
described in the DT. This has the added advantage of not requiring new
compatible strings for new SoCs when just the number of PHYs change, which
already happened and might occur again in the future.
Drop the num_phys member from the config struct, and remove the fixed
number of PHYs from each SoC's config description. Then enumerate the
usb<x>_reset properties for all of the maximum four PHY instances, and
just stop once we cannot find such a property anymore.
The binding describes the reset property as mandatory for each PHY
instance, and each DT in the kernel tree matches exactly the num_phys
value in the current driver code, so we can rely on that.
Apart from being more future proof, this will solve the A523 mishap:
Older DTs would just describe two PHYs, whereas newer ones would feature
all three of them. In any case we would get a valid number, matching the
other nodes in the DT. Older kernels would always enumerate two PHYs,
which at least does not cause any regressions.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Link: https://lore.kernel.org/r/20250819001522.13011-1-andre.przywara@arm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The PCIe Gen3 x2 PHY for SM8750 uses new phy, add the
required registers and offsets for this phy.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250809-pakala-v1-2-abf1c416dbaa@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add support for the eUSB2 repeater found on the PMIV0104. There is no
default init table for this PMIC, just the board-specific tuning
parameters are used on top of the default tuning values.
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20250709-sm7635-eusb-repeater-v2-4-b6eff075c097@fairphone.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Support reading the FS Differential TX Output Resistance Tuning from
devicetree and writing the register, as required on some boards.
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20250709-sm7635-eusb-repeater-v2-2-b6eff075c097@fairphone.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Since commit 4fd06af96b ("usb: phy: omap-control: Get rid of platform
data") the driver only supports OF probe so drop the unused platform
module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724154823.15998-12-johan@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The driver has never supported anything but OF probe so drop the unused
platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724154823.15998-11-johan@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Since commit 918ee0d21b ("usb: phy: omap-usb3: Don't use
omap_get_control_dev()") the driver only supports OF probe so drop the
unused platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724154823.15998-10-johan@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Since commit 478b6c7436 ("usb: phy: omap-usb2: Don't use
omap_get_control_dev()") the driver only supports OF probe so drop the
unused platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724154823.15998-9-johan@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The driver has never supported anything but OF probe so drop the unused
platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724154823.15998-8-johan@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The driver has never supported anything but OF probe so drop the unused
platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724154823.15998-7-johan@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The driver has never supported anything but OF probe so drop the unused
platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724154823.15998-6-johan@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The driver has never supported anything but OF probe so drop the unused
platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724154823.15998-5-johan@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The driver has never supported anything but OF probe so drop the unused
platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724154823.15998-4-johan@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Since commit 9d5f51dcdb ("phy: usb: Add support for new Synopsys USB
controller on the 7211b0") the driver only supports OF probe so drop the
unused platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724154823.15998-3-johan@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Linus Torvalds
Nicolas Frattaroli
Michael Riesch
Harikrishna Shenoy
Michael Dege
Inochi Amaoto
Devarsh Thakkar
Stephan Gerhold
Lad Prabhakar
Michael Walle
Josua Mayer
Prashanth K
Liao Yuanhong
Nitin Rawat
Akhilesh Patil
Neil Armstrong
Konrad Dybcio
Chen Ni
Wolfram Sang
Andre Przywara
Krishna Chaitanya Chundru
Luca Weiss
Johan Hovold