linux-stable.git/drivers/phy, branch v7.2.6 Linux kernel stable tree phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes 2026-09-14T11:40:40+00:00 Cristian Ciocaltea cristian.ciocaltea@collabora.com 2026-08-11T15:44:46+00:00 99c91dca54a6c54234080d72bdf50e3239be601b [ Upstream commit aec3e4ce25da4ed37bbbfedcbb7107ae9428b183 ] Any changes to the PHY link rate and/or color depth done via the HDMI PHY configuration API are not immediately programmed into the hardware, but are delayed until the PHY usage count gets incremented from 0 to 1, that is when it is powered on or when the PLL clock exposed through the CCF API is prepared, whichever comes first. Since the clock might remain in prepared state after subsequent PHY config changes, the programming can also be triggered via clk_ops.set_rate(). However, from the clock consumer perspective (i.e. VOP2 display controller), the (pixel) clock rate doesn't vary with bpc, as that is handled internally by the PHY and reflected in the TDMS character rate only. As a consequence, changing the bpc while preserving the modeline may lead to out-of-sync issues between CCF and HDMI PHY config state, because the .set_rate() callback is not invoked when clock rate remains constant. This may also happen when the PHY PLL has been pre-programmed by an external entity, e.g. the bootloader, which is actually a regression introduced by the recent FRL-related changes. Introduce a pll_config_dirty flag to keep track of uncommitted PHY config changes and use it in clk_ops.determine_rate() to invalidate the current clock rate (as known by CCF) and, consequently, ensure those changes are programmed into hardware via clk_ops.set_rate(). Moreover, proceed with a similar fix in phy_ops.power_on() callback, to handle the scenario where the CCF API is not used due to operating in FRL mode, while the clock is still in a prepared state and thus preventing rk_hdptx_phy_consumer_get() to apply the updated PHY configuration. Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support") Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management") Tested-by: Thomas Niederprüm <dubito@online.de> Tested-by: Simon Wright <simon@symple.nz> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-5-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit aec3e4ce25da4ed37bbbfedcbb7107ae9428b183 ]

Any changes to the PHY link rate and/or color depth done via the HDMI
PHY configuration API are not immediately programmed into the hardware,
but are delayed until the PHY usage count gets incremented from 0 to 1,
that is when it is powered on or when the PLL clock exposed through
the CCF API is prepared, whichever comes first.

Since the clock might remain in prepared state after subsequent PHY
config changes, the programming can also be triggered via
clk_ops.set_rate().  However, from the clock consumer perspective (i.e.
VOP2 display controller), the (pixel) clock rate doesn't vary with bpc,
as that is handled internally by the PHY and reflected in the TDMS
character rate only.

As a consequence, changing the bpc while preserving the modeline may
lead to out-of-sync issues between CCF and HDMI PHY config state,
because the .set_rate() callback is not invoked when clock rate remains
constant.  This may also happen when the PHY PLL has been pre-programmed
by an external entity, e.g. the bootloader, which is actually a
regression introduced by the recent FRL-related changes.

Introduce a pll_config_dirty flag to keep track of uncommitted PHY
config changes and use it in clk_ops.determine_rate() to invalidate the
current clock rate (as known by CCF) and, consequently, ensure those
changes are programmed into hardware via clk_ops.set_rate().

Moreover, proceed with a similar fix in phy_ops.power_on() callback, to
handle the scenario where the CCF API is not used due to operating in
FRL mode, while the clock is still in a prepared state and thus
preventing rk_hdptx_phy_consumer_get() to apply the updated PHY
configuration.

Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support")
Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management")
Tested-by: Thomas Niederprüm <dubito@online.de>
Tested-by: Simon Wright <simon@symple.nz>
Tested-by: Diederik de Haas <diederik@cknow-tech.com>  # NanoPC-T6 LTS
Reviewed-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-5-75bca0ee5753@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
phy: rockchip: samsung-hdptx: Fix rate recalculation for 3.2GHz FRL 2026-09-14T11:40:40+00:00 Cristian Ciocaltea cristian.ciocaltea@collabora.com 2026-08-11T15:44:45+00:00 c4506784a95ced768d6ba342b943dec14b74e770 [ Upstream commit 9ac3daadb9060360e937a5993a5fd88360d6fdad ] rk_hdptx_phy_clk_calc_rate_from_pll_cfg() is currently unable to handle cascade mode for the 3.2GHz FRL operating mode, as it relies solely on LCPLL_LCVCO_MODE_EN_MASK to determinate the rate from the rk_hdptx_frl_lcpll_cfg array. Since there is no entry for this particular rate, the function returns 0. This is the only rate which requires LC_REF_CLK_SEL to be set in GRF_HDPTX_CON0, hence extend the FRL matching accordingly. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1 Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support") Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-4-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9ac3daadb9060360e937a5993a5fd88360d6fdad ]

rk_hdptx_phy_clk_calc_rate_from_pll_cfg() is currently unable to handle
cascade mode for the 3.2GHz FRL operating mode, as it relies solely on
LCPLL_LCVCO_MODE_EN_MASK to determinate the rate from the
rk_hdptx_frl_lcpll_cfg array.  Since there is no entry for this
particular rate, the function returns 0.

This is the only rate which requires LC_REF_CLK_SEL to be set in
GRF_HDPTX_CON0, hence extend the FRL matching accordingly.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1
Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support")
Tested-by: Diederik de Haas <diederik@cknow-tech.com>  # NanoPC-T6 LTS
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-4-75bca0ee5753@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
phy: rockchip: samsung-hdptx: Guard against clk rate integer underflow 2026-09-14T11:40:40+00:00 Cristian Ciocaltea cristian.ciocaltea@collabora.com 2026-08-11T15:44:44+00:00 0a111684ed66339cfce5cc5583e0ba1e23ed8fc3 [ Upstream commit 229788526ff24e0607726e93b74dd2ef157a99cd ] The 'fout' subtraction in rk_hdptx_phy_clk_calc_rate_from_pll_cfg() could result in an integer underflow, if the hardware registers are misconfigured or contain uninitialized values, such that the computed sigma-delta modulator offset sdm exceeds the base frequency fout. This might lead to an absurdly high clock rate being returned to the Common Clock Framework, with unpredictable effects on downstream clk consumers. Provide the necessary sanitization to avoid trusting the hardware state. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260611235702.0E9691F000E9@smtp.kernel.org/ Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-3-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 229788526ff24e0607726e93b74dd2ef157a99cd ]

The 'fout' subtraction in rk_hdptx_phy_clk_calc_rate_from_pll_cfg()
could result in an integer underflow, if the hardware registers are
misconfigured or contain uninitialized values, such that the computed
sigma-delta modulator offset sdm exceeds the base frequency fout.

This might lead to an absurdly high clock rate being returned to the
Common Clock Framework, with unpredictable effects on downstream clk
consumers.

Provide the necessary sanitization to avoid trusting the hardware state.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260611235702.0E9691F000E9@smtp.kernel.org/
Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-3-75bca0ee5753@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk rate 2026-09-14T11:40:39+00:00 Cristian Ciocaltea cristian.ciocaltea@collabora.com 2026-08-11T15:44:43+00:00 877657310a66bf2b65a6efd5fb5b8a00cec6aefa [ Upstream commit c4fe5a9f379055ce0ec930f6495ae62aad237b89 ] Calculating 'sdm' fraction in rk_hdptx_phy_clk_calc_rate_from_pll_cfg() could trigger a divide-by-zero, as it uses div_u64() with a denominator read directly from hardware: the values ropll_hw.sdm_deno, ropll_hw.sdc_deno, ropll_hw.sdc_n, and ropll_hw.sdc_num are populated from PLL registers which, in theory, could be left by the bootloader uninitialized/misconfigured. Provide the necessary sanitization to avoid trusting the hardware state. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1 Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-2-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c4fe5a9f379055ce0ec930f6495ae62aad237b89 ]

Calculating 'sdm' fraction in rk_hdptx_phy_clk_calc_rate_from_pll_cfg()
could trigger a divide-by-zero, as it uses div_u64() with a denominator
read directly from hardware: the values ropll_hw.sdm_deno,
ropll_hw.sdc_deno, ropll_hw.sdc_n, and ropll_hw.sdc_num are populated
from PLL registers which, in theory, could be left by the bootloader
uninitialized/misconfigured.

Provide the necessary sanitization to avoid trusting the hardware state.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1
Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config")
Tested-by: Diederik de Haas <diederik@cknow-tech.com>  # NanoPC-T6 LTS
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-2-75bca0ee5753@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc 2026-09-14T11:40:39+00:00 Cristian Ciocaltea cristian.ciocaltea@collabora.com 2026-08-11T15:44:42+00:00 b6823d7f95abcae35338bf66e6886013a3e3191b [ Upstream commit f0c2c9c58a48b621b1cb90f0821da422b31af814 ] The PHY PLL can be programmed by an external component, e.g. the bootloader, just before the recalc_rate() callback is invoked during devm_clk_hw_register() in the probe path. Therefore rk_hdptx_phy_clk_recalc_rate() finds the PLL enabled and attempts to compute the clock rate, while making use of the bpc value from the HDMI PHY configuration, which always defaults to 8 because phy_configure() was not run at that point. As a consequence, the (re)calculated rate is incorrect when the actual bpc was higher than 8. Do not rely on any of the hdmi_cfg members when computing the clock rate and, instead, read the required input data (i.e. bpc), directly from the hardware registers. Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Tested-by: Thomas Niederprüm <dubito@online.de> Tested-by: Simon Wright <simon@symple.nz> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Andy Yan <andyshrk@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-1-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f0c2c9c58a48b621b1cb90f0821da422b31af814 ]

The PHY PLL can be programmed by an external component, e.g. the
bootloader, just before the recalc_rate() callback is invoked during
devm_clk_hw_register() in the probe path.

Therefore rk_hdptx_phy_clk_recalc_rate() finds the PLL enabled and
attempts to compute the clock rate, while making use of the bpc value
from the HDMI PHY configuration, which always defaults to 8 because
phy_configure() was not run at that point.  As a consequence, the
(re)calculated rate is incorrect when the actual bpc was higher than 8.

Do not rely on any of the hdmi_cfg members when computing the clock rate
and, instead, read the required input data (i.e. bpc), directly from the
hardware registers.

Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config")
Tested-by: Thomas Niederprüm <dubito@online.de>
Tested-by: Simon Wright <simon@symple.nz>
Tested-by: Diederik de Haas <diederik@cknow-tech.com>  # NanoPC-T6 LTS
Reviewed-by: Andy Yan <andyshrk@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-1-75bca0ee5753@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy 2026-09-14T11:40:38+00:00 Esteban Urrutia esteuwu@proton.me 2026-07-12T03:13:18+00:00 fdda85094b2f6f77b5d2d934aaa6c8969fd48c71 [ Upstream commit 8fd2b30d187fa33e5dd30699d3e3a3662c1610c9 ] There are no downstream device trees that specify five values in the qcom,aux-cfg1-settings array. Plus, after cross referencing both downstream device trees and entries which refer this function, only 0x13 is specified. Since 0x13 is written at initialization time, drop this function as a whole, and remove now unused variable assignations. Fixes: aff188feb5e1 ("phy: qcom-qmp: add support for sm8250-usb3-dp phy") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Esteban Urrutia <esteuwu@proton.me> Link: https://patch.msgid.link/20260711-sm8450-qol-qmp-v2-2-d14353bd6ff4@proton.me Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8fd2b30d187fa33e5dd30699d3e3a3662c1610c9 ]

There are no downstream device trees that specify five values in the
qcom,aux-cfg1-settings array.
Plus, after cross referencing both downstream device trees and entries
which refer this function, only 0x13 is specified.
Since 0x13 is written at initialization time, drop this function as a
whole, and remove now unused variable assignations.

Fixes: aff188feb5e1 ("phy: qcom-qmp: add support for sm8250-usb3-dp phy")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
Link: https://patch.msgid.link/20260711-sm8450-qol-qmp-v2-2-d14353bd6ff4@proton.me
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
phy: qcom: qmp-combo: Correct pre-emphasis table for QMP v4 DP PHYs 2026-09-14T11:40:37+00:00 Esteban Urrutia esteuwu@proton.me 2026-07-12T03:13:17+00:00 8dda7211be1ea81fdbd54315443cbca2178b3e9c [ Upstream commit 481807f939077059db278edd0467e7e609b6c9a7 ] Comparing sm8350 and sm8450 tables, this seems to be a typo. Fixes: ef14aff107bd ("phy: qcom: com-qmp-combo: add SM8350 & SM8450 support") Signed-off-by: Esteban Urrutia <esteuwu@proton.me> Link: https://patch.msgid.link/20260711-sm8450-qol-qmp-v2-1-d14353bd6ff4@proton.me Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 481807f939077059db278edd0467e7e609b6c9a7 ]

Comparing sm8350 and sm8450 tables, this seems to be a typo.

Fixes: ef14aff107bd ("phy: qcom: com-qmp-combo: add SM8350 & SM8450 support")
Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
Link: https://patch.msgid.link/20260711-sm8450-qol-qmp-v2-1-d14353bd6ff4@proton.me
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
phy: renesas: rcar-gen3-usb2: Ignore missing VBUS regulator 2026-09-14T11:40:37+00:00 Lad Prabhakar prabhakar.mahadev-lad.rj@bp.renesas.com 2026-07-02T12:58:55+00:00 8ecad7d61482ff77fa1f32dbcbf1bb23d00b5dc3 [ Upstream commit 9ea8d49c6cc6e217f5f5818369f659dc25bf89bf ] Commit b6d7dd157763 ("phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control") introduced support for controlling OTG VBUS through the regulator framework. As part of this change, the driver started requesting an exclusive "vbus" regulator for OTG-capable PHYs with no_adp_ctrl set. The lookup failure was propagated unconditionally, causing probe to fail on platforms where no VBUS regulator is described. On RZ/V2H and RZ/V2N, which do not use a VBUS regulator, this results in the following error: phy_rcar_gen3_usb2 15800200.usb-phy: dummy supplies not allowed for exclusive requests (id=vbus) This failure completely prevents the USB 2.0 interface from initializing. Fix this by allowing the probe to continue if an external VBUS regulator is missing. Only propagate the error if the internal vbus-regulator node is explicitly present, or if the lookup returns -EPROBE_DEFER. For all other missing regulator errors, gracefully assume no external VBUS regulator is available and return 0. Fixes: b6d7dd157763 ("phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260702125855.3157253-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9ea8d49c6cc6e217f5f5818369f659dc25bf89bf ]

Commit b6d7dd157763 ("phy: renesas: rcar-gen3-usb2: Add regulator for
OTG VBUS control") introduced support for controlling OTG VBUS through
the regulator framework.

As part of this change, the driver started requesting an exclusive "vbus"
regulator for OTG-capable PHYs with no_adp_ctrl set. The lookup failure
was propagated unconditionally, causing probe to fail on platforms where
no VBUS regulator is described.

On RZ/V2H and RZ/V2N, which do not use a VBUS regulator, this results
in the following error:

    phy_rcar_gen3_usb2 15800200.usb-phy:
    dummy supplies not allowed for exclusive requests (id=vbus)

This failure completely prevents the USB 2.0 interface from initializing.

Fix this by allowing the probe to continue if an external VBUS regulator
is missing. Only propagate the error if the internal vbus-regulator node
is explicitly present, or if the lookup returns -EPROBE_DEFER. For all
other missing regulator errors, gracefully assume no external VBUS
regulator is available and return 0.

Fixes: b6d7dd157763 ("phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Link: https://patch.msgid.link/20260702125855.3157253-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
phy: qcom: qmp-pcie: Add pcs_lane1 offset to V5 offsets 2026-09-14T11:40:27+00:00 Esteban Urrutia esteuwu@proton.me 2026-07-15T06:37:47+00:00 0fef3967ccb8e9655ea086cfef79a08b6453d375 [ Upstream commit f8b4493d5e7e19682abcf538a9faad012b5ef69e ] Some SoCs such as SM8475 write data to registers using this offset, specifically SW_CTRL2 and MX_CTRL2. Add pcs_lane1 offset to V5 offsets to support this. Signed-off-by: Esteban Urrutia <esteuwu@proton.me> Fixes: 0fd0b31965b0 ("phy: qualcomm: qmp-pcie: add support for SAR2130P") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260715-sm8475-bup-pcie-v2-2-48bd91a19abf@proton.me Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f8b4493d5e7e19682abcf538a9faad012b5ef69e ]

Some SoCs such as SM8475 write data to registers using this offset,
specifically SW_CTRL2 and MX_CTRL2.
Add pcs_lane1 offset to V5 offsets to support this.

Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
Fixes: 0fd0b31965b0 ("phy: qualcomm: qmp-pcie: add support for SAR2130P")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20260715-sm8475-bup-pcie-v2-2-48bd91a19abf@proton.me
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend 2026-09-14T11:40:27+00:00 Loic Poulain loic.poulain@oss.qualcomm.com 2026-07-22T13:45:19+00:00 03455404fb6cbfd65842695df26739853fc1516b [ Upstream commit 142c5593379273264474f31d5956b1a0065cd576 ] There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer. Fixes: e464a3180a43 ("phy: qcom-qmp-usb: split off the legacy USB+dp_com support") Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260722-qcom-usb-phy-fix-null-v6-6-534f7e61b9a6@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 142c5593379273264474f31d5956b1a0065cd576 ]

There is a small window where the runtime suspend callback may run
after pm_runtime_enable() and before pm_runtime_forbid(). In this
case, a crash occurs because runtime suspend/resume dereferences
qmp->phy pointer, which is not yet initialized:
        `if (!qmp->phy->init_count) {`

This can also happen if user re-enables runtime-pm via the sysfs
attribute before qmp phy is initialized.

Similarly to other qcom phy drivers, introduce a qmp->phy_initialized
variable that can be used to avoid relying on the possibly uninitialized
phy pointer.

Fixes: e464a3180a43 ("phy: qcom-qmp-usb: split off the legacy USB+dp_com support")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20260722-qcom-usb-phy-fix-null-v6-6-534f7e61b9a6@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>