* Re: [PATCH 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add vdda-refgen supply for Glymur
From: Dmitry Baryshkov @ 2026-02-13 17:47 UTC (permalink / raw)
To: Qiang Yu
Cc: Krzysztof Kozlowski, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <aY1Jx5J8x/OALk5M@hu-qianyu-lv.qualcomm.com>
On Wed, Feb 11, 2026 at 07:32:23PM -0800, Qiang Yu wrote:
> On Mon, Feb 09, 2026 at 09:06:23AM +0100, Krzysztof Kozlowski wrote:
> > On Sun, Feb 08, 2026 at 08:49:39PM -0800, Qiang Yu wrote:
> > > The PCIe QMP PHYs on Glymur require stable reference voltage provided by
> > > refgen. The refgen itself requires two separate power supplies:
> > > vdda-refgen0p9 and vdda-refgen1p2.
> > >
> > > Since there is no dedicated driver for REFGEN, add vdda-refgen0p9-supply
> >
> > How does the driver matter for the bindings? If I add dedicated driver
> > for refgen, then I change the bindings?
>
> Yeah, I know that dt-bindings should describe hardware, not software. But
> what I meant to say is that the refgen is different from qref which is
> controlled via TCSR registers and its LDOs are requested to vote in
> tcsrcc driver. The refgen doesn't required register setting and it doesn't
> have dedicated driver, so we vote its LDOs in phy driver. I will avoid
> this statement in next version.
I must admit, I could not find references to the refgen in any of Glymur
PCIe-related HPGs.
>
> >
> > There is qcom,sc8280xp-refgen-regulator so why there cannot be
> > qcom,x1e-refgen-regulator?
>
> I think we can and it seems better because the refgen for pcie phy also
> supplies reference voltage to other modules like usb. But I checked the
> qcom-refgen-regulator.c, it contains some register settings and there is
> no LDOs voting. I'm not sure what does those register do, maybe Konrad
> can provide some backgroud.
Those regs provide voting for refgen, because on those platforms DSI
block doesn't have a hardware vote for refgen.
> But on Glymur, we only need to vote LDOs. So
> what if we use a fixed regulator in the device tree to represent refgen?
> We could set refgen0p9 and refgen1p2 as its input supplies, then the PCIe
> PHY would just need one refgen supply reference.
>
> - Qiang Yu
> >
> >
> > > and vdda-refgen1p2-supply properties to the PCIe PHY dt-bindings. Use
> > > conditional schema to restrict these properties to only Glymur PCIe QMP
> > > PHYs.
> >
> > Best regards,
> > Krzysztof
> >
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v4 0/3] dt-bindings: phy: Convert TI OMAP control and PIPE3 PHY to DT schema
From: Charan Pedumuru @ 2026-02-13 16:36 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap
In-Reply-To: <177021985530.133434.13436195442562231016.b4-ty@kernel.org>
On 04-02-2026 21:14, Vinod Koul wrote:
>
> On Fri, 23 Jan 2026 15:39:01 +0000, Charan Pedumuru wrote:
>> This series converts the old text-based DeviceTree bindings for TI OMAP
>> Control PHY and TI PIPE3 PHY to modern JSON-schema (YAML) format.
>>
>>
>
> Applied, thanks!
>
> [2/3] dt-bindings: phy: ti,phy-usb3: convert to DT schema
> commit: 62c9ff8fc20d23c0dc36be1330734fdafb3e8585
> [3/3] dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
> commit: 7878306d182a1750583a325a29e5ccab9ce0235b
Hi Vinod,
You missed to apply the first patch which has DT node pattern changes and now this dtb check fails in linux-next as these YAML patches use the updated node pattern. I got a report of errors from kernel test robot.
>
> Best regards,
--
Best Regards,
Charan.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 0/2] phy: qcom: edp: Add DP/eDP switch for phys
From: Dmitry Baryshkov @ 2026-02-13 16:12 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, stable
In-Reply-To: <20260213-edp_phy-v2-0-43c40976435e@oss.qualcomm.com>
On Fri, Feb 13, 2026 at 03:31:41PM +0800, Yongxing Mou wrote:
> Currently the PHY selects the DP/eDP configuration tables in a fixed way,
> choosing the table when enable. This driver has known issues:
> 1. The selected table does not match the actual platform mode.
> 2. It cannot support both modes at the same time.
>
> As discussed here[1], this series:
> 1. Cleans up duplicated and incorrect tables based on the HPG.
> 2. Fixes the LDO programming error in eDP mode.
> 3. Adds DP/eDP mode switching support.
>
> Note: x1e80100/sa8775p/sc7280 have been tested, while glymur/sc8280xp
> have not been tested.
>
> [1] https://lore.kernel.org/all/20260119-klm_dpphy-v2-1-52252190940b@oss.qualcomm.com/
>
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---
> Changes in v2:
> - Combine the third patch with the first one.[Dmitry]
> - Fix code formatting issues.[Konrad][Dmitry]
> - Update the commit message description.[Dmitry][Konrad]
> - Fix kodiak swing/pre_emp table values.[Konrad]
> - Link to v1: https://lore.kernel.org/r/20260205-edp_phy-v1-0-231882bbf3f1@oss.qualcomm.com
>
> ---
> Yongxing Mou (2):
> phy: qcom: edp: Add eDP/DP mode switch support
> phy: qcom: edp: Add per-version LDO configuration callback
>
> drivers/phy/qualcomm/phy-qcom-edp.c | 176 ++++++++++++++++++++++++++----------
> 1 file changed, 129 insertions(+), 47 deletions(-)
> ---
> base-commit: fc4e91c639c0af93d63c3d5bc0ee45515dd7504a
20260108 is very old. Your second patch doesn't apply anymore.
> change-id: 20260205-edp_phy-1eca3ed074c0
>
> Best regards,
> --
> Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-02-13 15:04 UTC (permalink / raw)
To: Johan Hovold
Cc: vkoul, kishon, linux-arm-msm, linux-phy, dmitry.baryshkov,
neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <aY8Asvu-1u0e02oJ@hovoldconsulting.com>
On Fri, Feb 13, 2026 at 11:45 AM Johan Hovold <johan@kernel.org> wrote:
>
> On Fri, Feb 13, 2026 at 10:45:32AM +0100, Loic Poulain wrote:
> > On Fri, Feb 13, 2026 at 10:07 AM Johan Hovold <johan@kernel.org> wrote:
> > >
> > > On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> > > > Enabling runtime PM before attaching the hsphy instance as driver data
> > > > can lead to a NULL pointer dereference in runtime PM callbacks that
> > > > expect valid driver data. There is a small window where the suspend
> > > > callback may run after PM runtime enabling and before runtime forbid.
> > >
> > > So here too, the commit should reflect that this cannot really happen in
> > > practice.
> >
> > This happened in practice in the qcom‑qusb2 PHY driver, with the same
> > code flow.
> > Bug: https://github.com/qualcomm-linux/qcom-deb-images/issues/208
> > Patch: https://lore.kernel.org/linux-arm-msm/20251219085640.114473-1-loic.poulain@oss.qualcomm.com/
>
> Thanks for the link.
>
> > I know it may sound unlikely, but this crash has been reported
> > several times during boot‑stress testing. I haven’t investigated
> > deeply enough to determine whether it’s caused by an unfortunate
> > preemption window or a racing CPU.
>
> But I'm literally asking for *what* would trigger the suspend in that
> initial window between enable() and forbid() cause I don't see it.
To be honest, I had not initially looked into the exact cause of the
suspend trigger until now, but here is what is happening.
The PHY is a supplier of the USB device. A USB device cannot be probed
until all its suppliers are ready. As long as the PHY is not ready, the
device core keeps retrying the probe, which fails with -EPROBE_DEFER.
At some point the PHY probe finally runs, but the device core may still be
attempting to probe the USB device concurrently.
Inside __driver_probe_device(), we have:
ret = really_probe(dev, drv);
pm_request_idle(dev);
if (dev->parent)
pm_runtime_put(dev->parent);
pm_runtime_put_suppliers(dev);
return ret;
This means that whenever a USB probe attempt completes, whether with an
error or not, its suppliers are released via pm_runtime_put_suppliers().
Releasing suppliers may in turn trigger a runtime suspend.
In our case, since the PHY is a supplier of the USB device, the USB core
keeps 'looping' in __driver_probe_device() returning -EPROBE_DEFER until
the PHY becomes ready. As a result, pm_runtime_put_suppliers() may run
concurrently with the PHY's probe function. If this happens after
runtime PM has been enabled for the PHY, but before the driver has
forbidden suspend or taken a PM reference, the PHY may end up being
runtime-suspended 'unexpectedly'.
Regards,
Loic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 7/9] phy: rockchip: usbdp: Rename DP lane functions
From: Sebastian Reichel @ 2026-02-13 14:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang
Cc: Andy Yan, Yubing Zhang, Alexey Charkov, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel
In-Reply-To: <20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com>
The common prefix for DisplayPort related functions is rk_udphy_dp_
(with a final _), so update the two DP lane functions to follow that
scheme.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index bf8394174294..6d7ca11b308e 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -547,7 +547,7 @@ static void rk_udphy_usb_bvalid_enable(struct rk_udphy *udphy, u8 enable)
* ---------------------------------------------------------------------------
*/
-static void rk_udphy_dplane_select(struct rk_udphy *udphy)
+static void rk_udphy_dp_lane_select(struct rk_udphy *udphy)
{
const struct rk_udphy_cfg *cfg = udphy->cfgs;
u32 value = 0;
@@ -576,7 +576,7 @@ static void rk_udphy_dplane_select(struct rk_udphy *udphy)
FIELD_PREP(DP_AUX_DOUT_SEL, udphy->dp_aux_dout_sel) | value);
}
-static void rk_udphy_dplane_enable(struct rk_udphy *udphy, int dp_lanes)
+static void rk_udphy_dp_lane_enable(struct rk_udphy *udphy, int dp_lanes)
{
u32 val = 0;
int i;
@@ -1072,9 +1072,9 @@ static int rk_udphy_dp_phy_power_on(struct phy *phy)
if (ret)
goto unlock;
- rk_udphy_dplane_enable(udphy, udphy->dp_lanes);
+ rk_udphy_dp_lane_enable(udphy, udphy->dp_lanes);
- rk_udphy_dplane_select(udphy);
+ rk_udphy_dp_lane_select(udphy);
unlock:
mutex_unlock(&udphy->mutex);
@@ -1092,7 +1092,7 @@ static int rk_udphy_dp_phy_power_off(struct phy *phy)
struct rk_udphy *udphy = phy_get_drvdata(phy);
mutex_lock(&udphy->mutex);
- rk_udphy_dplane_enable(udphy, 0);
+ rk_udphy_dp_lane_enable(udphy, 0);
rk_udphy_power_off(udphy, UDPHY_MODE_DP);
mutex_unlock(&udphy->mutex);
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 8/9] phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST
From: Sebastian Reichel @ 2026-02-13 14:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang
Cc: Andy Yan, Yubing Zhang, Alexey Charkov, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel
In-Reply-To: <20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com>
Cleanup code by replacing open-coded version of FIELD_PREP_WM16_CONST
with the existing helper macro.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 6d7ca11b308e..1bfc365e2b2c 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -12,6 +12,7 @@
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/gpio.h>
+#include <linux/hw_bitfield.h>
#include <linux/mfd/syscon.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
@@ -75,7 +76,6 @@
#define TRSV_LN2_MON_RX_CDR_DONE_OFFSET 0x1b84 /* trsv_reg06E1 */
#define TRSV_LN2_MON_RX_CDR_LOCK_DONE BIT(0)
-#define BIT_WRITEABLE_SHIFT 16
#define PHY_AUX_DP_DATA_POL_NORMAL 0
#define PHY_AUX_DP_DATA_POL_INVERT 1
#define PHY_LANE_MUX_USB 0
@@ -104,8 +104,8 @@ struct rk_udphy_grf_reg {
#define _RK_UDPHY_GEN_GRF_REG(offset, mask, disable, enable) \
{\
offset, \
- FIELD_PREP_CONST(mask, disable) | (mask << BIT_WRITEABLE_SHIFT), \
- FIELD_PREP_CONST(mask, enable) | (mask << BIT_WRITEABLE_SHIFT), \
+ FIELD_PREP_WM16_CONST(mask, disable), \
+ FIELD_PREP_WM16_CONST(mask, enable), \
}
#define RK_UDPHY_GEN_GRF_REG(offset, bitend, bitstart, disable, enable) \
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 5/9] phy: rockchip: usbdp: Add missing mode_change update
From: Sebastian Reichel @ 2026-02-13 14:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang
Cc: Andy Yan, Yubing Zhang, Alexey Charkov, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel
In-Reply-To: <20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com>
rk_udphy_set_typec_default_mapping() updates the available modes,
but does not set the mode_change as required. This results in
missing re-initialization and thus non-working DisplayPort.
Fix this issue by introducing a new helper to update the available
modes.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 97e53b933225..febc148a754e 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -619,6 +619,15 @@ static void rk_udphy_dp_hpd_event_trigger(struct rk_udphy *udphy, bool hpd)
rk_udphy_grfreg_write(udphy->vogrf, &cfg->vogrfcfg[udphy->id].hpd_trigger, hpd);
}
+static void rk_udphy_mode_set(struct rk_udphy *udphy, u8 mode)
+{
+ if (udphy->mode == mode)
+ return;
+
+ udphy->mode_change = true;
+ udphy->mode = mode;
+}
+
static void rk_udphy_set_typec_default_mapping(struct rk_udphy *udphy)
{
if (udphy->flip) {
@@ -649,7 +658,7 @@ static void rk_udphy_set_typec_default_mapping(struct rk_udphy *udphy)
gpiod_set_value_cansleep(udphy->sbu2_dc_gpio, 1);
}
- udphy->mode = UDPHY_MODE_DP_USB;
+ rk_udphy_mode_set(udphy, UDPHY_MODE_DP_USB);
}
static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
@@ -1385,10 +1394,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
usleep_range(750, 800);
rk_udphy_dp_hpd_event_trigger(udphy, true);
} else if (data->status & DP_STATUS_HPD_STATE) {
- if (udphy->mode != mode) {
- udphy->mode = mode;
- udphy->mode_change = true;
- }
+ rk_udphy_mode_set(udphy, mode);
rk_udphy_dp_hpd_event_trigger(udphy, true);
} else {
rk_udphy_dp_hpd_event_trigger(udphy, false);
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 9/9] phy: rockchip: usbdp: Cleanup DP lane selection function
From: Sebastian Reichel @ 2026-02-13 14:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang
Cc: Andy Yan, Yubing Zhang, Alexey Charkov, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel
In-Reply-To: <20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com>
Use FIELD_PREP_WM16() helpers to simplify the DP lane selection
logic.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 30 ++++++++----------------------
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 1bfc365e2b2c..c2f52b7125d3 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -3,7 +3,7 @@
* Rockchip USBDP Combo PHY with Samsung IP block driver
*
* Copyright (C) 2021-2024 Rockchip Electronics Co., Ltd
- * Copyright (C) 2024 Collabora Ltd
+ * Copyright (C) 2024-2026 Collabora Ltd
*/
#include <dt-bindings/phy/phy.h>
@@ -550,30 +550,16 @@ static void rk_udphy_usb_bvalid_enable(struct rk_udphy *udphy, u8 enable)
static void rk_udphy_dp_lane_select(struct rk_udphy *udphy)
{
const struct rk_udphy_cfg *cfg = udphy->cfgs;
- u32 value = 0;
-
- switch (udphy->dp_lanes) {
- case 4:
- value |= 3 << udphy->dp_lane_sel[3] * 2;
- value |= 2 << udphy->dp_lane_sel[2] * 2;
- fallthrough;
-
- case 2:
- value |= 1 << udphy->dp_lane_sel[1] * 2;
- fallthrough;
+ u32 value = FIELD_PREP_WM16(DP_LANE_SEL_ALL, 0);
+ int i;
- case 1:
- value |= 0 << udphy->dp_lane_sel[0] * 2;
- break;
+ for (i = 0; i < udphy->dp_lanes; i++)
+ value |= field_prep(DP_LANE_SEL_N(udphy->dp_lane_sel[i]), i);
- default:
- break;
- }
+ value |= FIELD_PREP_WM16(DP_AUX_DIN_SEL, udphy->dp_aux_din_sel);
+ value |= FIELD_PREP_WM16(DP_AUX_DOUT_SEL, udphy->dp_aux_dout_sel);
- regmap_write(udphy->vogrf, cfg->vogrfcfg[udphy->id].dp_lane_reg,
- ((DP_AUX_DIN_SEL | DP_AUX_DOUT_SEL | DP_LANE_SEL_ALL) << 16) |
- FIELD_PREP(DP_AUX_DIN_SEL, udphy->dp_aux_din_sel) |
- FIELD_PREP(DP_AUX_DOUT_SEL, udphy->dp_aux_dout_sel) | value);
+ regmap_write(udphy->vogrf, cfg->vogrfcfg[udphy->id].dp_lane_reg, value);
}
static void rk_udphy_dp_lane_enable(struct rk_udphy *udphy, int dp_lanes)
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 6/9] phy: rockchip: usbdp: Support single-lane DP
From: Sebastian Reichel @ 2026-02-13 14:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang
Cc: Andy Yan, Yubing Zhang, Alexey Charkov, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel
In-Reply-To: <20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com>
From: Zhang Yubing <yubing.zhang@rock-chips.com>
Implement support for using just a single DisplayPort line.
Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 61 +++++++++++++------------------
1 file changed, 25 insertions(+), 36 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index febc148a754e..bf8394174294 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -193,6 +193,7 @@ struct rk_udphy {
int id;
bool dp_in_use;
+ int dp_lanes;
/* PHY const config */
const struct rk_udphy_cfg *cfgs;
@@ -537,6 +538,13 @@ static void rk_udphy_usb_bvalid_enable(struct rk_udphy *udphy, u8 enable)
* <0 1> dpln0 dpln1 usbrx usbtx
* <2 3> usbrx usbtx dpln0 dpln1
* ---------------------------------------------------------------------------
+ * if 1 lane for dp function, 2 lane for usb function, define rockchip,dp-lane-mux = <x>;
+ * sample as follow:
+ * ---------------------------------------------------------------------------
+ * B11-B10 A2-A3 A11-A10 B2-B3
+ * rockchip,dp-lane-mux ln0(tx/rx) ln1(tx) ln2(tx/rx) ln3(tx)
+ * <0> dpln0 \ usbrx usbtx
+ * ---------------------------------------------------------------------------
*/
static void rk_udphy_dplane_select(struct rk_udphy *udphy)
@@ -544,18 +552,18 @@ static void rk_udphy_dplane_select(struct rk_udphy *udphy)
const struct rk_udphy_cfg *cfg = udphy->cfgs;
u32 value = 0;
- switch (udphy->mode) {
- case UDPHY_MODE_DP:
- value |= 2 << udphy->dp_lane_sel[2] * 2;
+ switch (udphy->dp_lanes) {
+ case 4:
value |= 3 << udphy->dp_lane_sel[3] * 2;
+ value |= 2 << udphy->dp_lane_sel[2] * 2;
fallthrough;
- case UDPHY_MODE_DP_USB:
- value |= 0 << udphy->dp_lane_sel[0] * 2;
+ case 2:
value |= 1 << udphy->dp_lane_sel[1] * 2;
- break;
+ fallthrough;
- case UDPHY_MODE_USB:
+ case 1:
+ value |= 0 << udphy->dp_lane_sel[0] * 2;
break;
default:
@@ -568,28 +576,6 @@ static void rk_udphy_dplane_select(struct rk_udphy *udphy)
FIELD_PREP(DP_AUX_DOUT_SEL, udphy->dp_aux_dout_sel) | value);
}
-static int rk_udphy_dplane_get(struct rk_udphy *udphy)
-{
- int dp_lanes;
-
- switch (udphy->mode) {
- case UDPHY_MODE_DP:
- dp_lanes = 4;
- break;
-
- case UDPHY_MODE_DP_USB:
- dp_lanes = 2;
- break;
-
- case UDPHY_MODE_USB:
- default:
- dp_lanes = 0;
- break;
- }
-
- return dp_lanes;
-}
-
static void rk_udphy_dplane_enable(struct rk_udphy *udphy, int dp_lanes)
{
u32 val = 0;
@@ -659,6 +645,7 @@ static void rk_udphy_set_typec_default_mapping(struct rk_udphy *udphy)
}
rk_udphy_mode_set(udphy, UDPHY_MODE_DP_USB);
+ udphy->dp_lanes = 2;
}
static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
@@ -897,7 +884,7 @@ static int rk_udphy_parse_lane_mux_data(struct rk_udphy *udphy)
return 0;
}
- if (num_lanes != 2 && num_lanes != 4)
+ if (num_lanes != 1 && num_lanes != 2 && num_lanes != 4)
return dev_err_probe(udphy->dev, -EINVAL,
"invalid number of lane mux\n");
@@ -923,7 +910,8 @@ static int rk_udphy_parse_lane_mux_data(struct rk_udphy *udphy)
}
udphy->mode = UDPHY_MODE_DP;
- if (num_lanes == 2) {
+ udphy->dp_lanes = num_lanes;
+ if (num_lanes == 1 || num_lanes == 2) {
udphy->mode |= UDPHY_MODE_USB;
udphy->flip = (udphy->lane_mux_sel[0] == PHY_LANE_MUX_DP);
}
@@ -1074,18 +1062,17 @@ static int rk_udphy_dp_phy_exit(struct phy *phy)
static int rk_udphy_dp_phy_power_on(struct phy *phy)
{
struct rk_udphy *udphy = phy_get_drvdata(phy);
- int ret, dp_lanes;
+ int ret;
mutex_lock(&udphy->mutex);
- dp_lanes = rk_udphy_dplane_get(udphy);
- phy_set_bus_width(phy, dp_lanes);
+ phy_set_bus_width(phy, udphy->dp_lanes);
ret = rk_udphy_power_on(udphy, UDPHY_MODE_DP);
if (ret)
goto unlock;
- rk_udphy_dplane_enable(udphy, dp_lanes);
+ rk_udphy_dplane_enable(udphy, udphy->dp_lanes);
rk_udphy_dplane_select(udphy);
@@ -1365,6 +1352,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
udphy->lane_mux_sel[2] = PHY_LANE_MUX_DP;
udphy->lane_mux_sel[3] = PHY_LANE_MUX_DP;
mode = UDPHY_MODE_DP;
+ udphy->dp_lanes = 4;
break;
case TYPEC_DP_STATE_D:
@@ -1381,6 +1369,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
udphy->lane_mux_sel[3] = PHY_LANE_MUX_DP;
}
mode = UDPHY_MODE_DP_USB;
+ udphy->dp_lanes = 2;
break;
}
@@ -1529,7 +1518,7 @@ static int rk_udphy_probe(struct platform_device *pdev)
ret = PTR_ERR(udphy->phy_dp);
return dev_err_probe(dev, ret, "failed to create DP phy\n");
}
- phy_set_bus_width(udphy->phy_dp, rk_udphy_dplane_get(udphy));
+ phy_set_bus_width(udphy->phy_dp, udphy->dp_lanes);
udphy->phy_dp->attrs.max_link_rate = 8100;
phy_set_drvdata(udphy->phy_dp, udphy);
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 3/9] phy: rockchip: usbdp: Amend SSC modulation deviation
From: Sebastian Reichel @ 2026-02-13 14:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang
Cc: Andy Yan, Yubing Zhang, Alexey Charkov, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel
In-Reply-To: <20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com>
From: Frank Wang <frank.wang@rock-chips.com>
Move SSC modulation deviation into private config of clock
- 24M: 0x00d4[5:0] = 0x30
- 26M: 0x00d4[5:0] = 0x33
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
[Taken over from rockchip's kernel tree; register 0x00d4 is not
described in the TRM]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 98562a888b42..1f686844c337 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -350,7 +350,8 @@ static const struct reg_sequence rk_udphy_24m_refclk_cfg[] = {
{0x0a64, 0xa8}, {0x1a3c, 0xd0},
{0x1a44, 0xd0}, {0x1a48, 0x01},
{0x1a4c, 0x0d}, {0x1a54, 0xe0},
- {0x1a5c, 0xe0}, {0x1a64, 0xa8}
+ {0x1a5c, 0xe0}, {0x1a64, 0xa8},
+ {0x00d4, 0x30}
};
static const struct reg_sequence rk_udphy_26m_refclk_cfg[] = {
@@ -377,7 +378,7 @@ static const struct reg_sequence rk_udphy_26m_refclk_cfg[] = {
{0x0c30, 0x0e}, {0x0c48, 0x06},
{0x1c30, 0x0e}, {0x1c48, 0x06},
{0x028c, 0x18}, {0x0af0, 0x00},
- {0x1af0, 0x00}
+ {0x1af0, 0x00}, {0x00d4, 0x33}
};
static const struct reg_sequence rk_udphy_init_sequence[] = {
@@ -412,8 +413,7 @@ static const struct reg_sequence rk_udphy_init_sequence[] = {
{0x0070, 0x7d}, {0x0074, 0x68},
{0x0af4, 0x1a}, {0x1af4, 0x1a},
{0x0440, 0x3f}, {0x10d4, 0x08},
- {0x20d4, 0x08}, {0x00d4, 0x30},
- {0x0024, 0x6e},
+ {0x20d4, 0x08}, {0x0024, 0x6e}
};
static inline int rk_udphy_grfreg_write(struct regmap *base,
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 2/9] phy: rockchip: usbdp: Keep clocks running on PHY re-init
From: Sebastian Reichel @ 2026-02-13 14:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang
Cc: Andy Yan, Yubing Zhang, Alexey Charkov, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel
In-Reply-To: <20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com>
When a mode change is required rk_udphy_power_on() disables the clocks
and then calls rk_udphy_setup(), which then enables all the clocks again
before continuing with rk_udphy_init().
Considering that rk_udphy_init() does assert the reset lines, re-enabling
the clocks is just delaying things. Avoid it by directly calling
rk_udphy_init() and skip the clock restart.
Keeping the time with non-working PHY on re-init as short as possible
helps (but does not fix!) a race-condition: The USB3 controller needs
the PHY running to access its registers. With the PHY stopped, accessing
the USB3 registers results in an SError. The re-init is usually
triggered by the DisplayPort controller driver requesting the DP's side
of the PHY. If the USB controller is already running at that point
(which is usually the case), the system can run into the SError.
A proper fix requires some API to lock/pause the USB controller from
the PHY side, which is a bigger change. Luckily this workaround, whichis
sensible anyways, I didn't manage to run into the SError. This is
most likely due to the fact that the DP driver will enable the DP PHY
directly after the USB-C cable is plugged in, before the USB driver is
aware of new devices being available.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 744cc7c642f4..98562a888b42 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1012,8 +1012,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
if (udphy->mode == UDPHY_MODE_DP)
rk_udphy_u3_port_disable(udphy, true);
- rk_udphy_disable(udphy);
- ret = rk_udphy_setup(udphy);
+ ret = rk_udphy_init(udphy);
if (ret)
return ret;
}
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 4/9] phy: rockchip: usbdp: Fix LFPS detect threshold control
From: Sebastian Reichel @ 2026-02-13 14:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang
Cc: Andy Yan, Yubing Zhang, Alexey Charkov, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel, William Wu
In-Reply-To: <20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com>
From: William Wu <william.wu@rock-chips.com>
According to the LFPS Tx Low Power/LFPS Rx Detect Threshold [1],
the device under test(DUT) must not respond if LFPS below the
minimum LFPS Rx Detect Threshold 100mV. Test fail on Rockchip
platforms, because the default LFPS detect threshold is set to
65mV.
The USBDP PHY LFPS detect threshold voltage could be set to
30mV ~ 140mV, and since there could be 10-20% PVT variation,
we set LFPS detect threshold voltage to 110mV.
[1] https://compliance.usb.org/resources/LFPS_Rx_Tx_Low_Power_Compliance_Update_Rev5.pdf
Signed-off-by: William Wu <william.wu@rock-chips.com>
[Taken over from rockchip's kernel tree; the registers are not described
in the TRM]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 1f686844c337..97e53b933225 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -413,7 +413,8 @@ static const struct reg_sequence rk_udphy_init_sequence[] = {
{0x0070, 0x7d}, {0x0074, 0x68},
{0x0af4, 0x1a}, {0x1af4, 0x1a},
{0x0440, 0x3f}, {0x10d4, 0x08},
- {0x20d4, 0x08}, {0x0024, 0x6e}
+ {0x20d4, 0x08}, {0x0024, 0x6e},
+ {0x09c0, 0x0a}, {0x19c0, 0x0a}
};
static inline int rk_udphy_grfreg_write(struct regmap *base,
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/9] phy: rockchip: usbdp: Fixes, DP 1-lane support and cleanups
From: Sebastian Reichel @ 2026-02-13 14:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang
Cc: Andy Yan, Yubing Zhang, Alexey Charkov, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel, William Wu
As there are some issues with the DisplayPort support, I went
though Rockchip's BSP kernel tree and looked for fixes. I found
two small changes for the initial register setup, which do not
help with the DP issue but seem sensible in general. Afterwards
I added one more fix, which corrects an issue that effectively
results in USB-C adapters with combined USB3+DP capabilities
not being able to use the DP part.
Afterwards I added one more patch adding single-lane DP support
(found in Rockchip BSP kernel) and a couple of cleanups from my
side. These are logically independent from the fixes, but I put
all together in a single series because they need to be applied
in the right order to avoid conflicts.
Changes in v2:
- Link to v1: https://lore.kernel.org/r/20260203-rockchip-usbdp-cleanup-v1-0-16a6f92ed176@collabora.com
- Added new patches to fix USB3 SError
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
Frank Wang (1):
phy: rockchip: usbdp: Amend SSC modulation deviation
Sebastian Reichel (6):
phy: rockchip: usbdp: Do not loose USB3 PHY status
phy: rockchip: usbdp: Keep clocks running on PHY re-init
phy: rockchip: usbdp: Add missing mode_change update
phy: rockchip: usbdp: Rename DP lane functions
phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST
phy: rockchip: usbdp: Cleanup DP lane selection function
William Wu (1):
phy: rockchip: usbdp: Fix LFPS detect threshold control
Zhang Yubing (1):
phy: rockchip: usbdp: Support single-lane DP
drivers/phy/rockchip/phy-rockchip-usbdp.c | 120 +++++++++++++-----------------
1 file changed, 50 insertions(+), 70 deletions(-)
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260203-rockchip-usbdp-cleanup-5b59dfb561a3
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 1/9] phy: rockchip: usbdp: Do not loose USB3 PHY status
From: Sebastian Reichel @ 2026-02-13 14:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang
Cc: Andy Yan, Yubing Zhang, Alexey Charkov, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel
In-Reply-To: <20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com>
By default (i.e. without manually enabling runtime PM) DWC3 requests the
USB3 PHY once and keeps it enabled all the time. When DisplayPort is
being requested later on, a mode change is needed. This re-initializes
the PHY. During re-initialization the status variable has incorrectly
been cleared, which means the tracking information for USB3 ist lost.
This is not an immediate problem, since the DP side keeps the PHY
enabled. But once DP is toggled off, the whole PHY will be disabled.
This is a problem, because the USB side still needs it powered.
Fix things by not clearing the status flags.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index fba35510d88c..744cc7c642f4 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1009,7 +1009,6 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
rk_udphy_u3_port_disable(udphy, false);
} else if (udphy->mode_change) {
udphy->mode_change = false;
- udphy->status = UDPHY_MODE_NONE;
if (udphy->mode == UDPHY_MODE_DP)
rk_udphy_u3_port_disable(udphy, true);
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH 0/7] phy: rockchip: usbdp: Fixes, DP 1-lane support and cleanups
From: Sebastian Reichel @ 2026-02-13 14:37 UTC (permalink / raw)
To: Andy Yan
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Andy Yan,
Yubing Zhang, linux-phy, linux-arm-kernel, linux-rockchip,
linux-kernel, kernel, Frank Wang, William Wu
In-Reply-To: <4a7a30c4.8848.19c288ea1f3.Coremail.andyshrk@163.com>
[-- Attachment #1.1: Type: text/plain, Size: 2208 bytes --]
Hi,
On Wed, Feb 04, 2026 at 08:09:22PM +0800, Andy Yan wrote:
> Hello Sebastian，
>
> At 2026-02-04 02:41:26, "Sebastian Reichel" <sebastian.reichel@collabora.com> wrote:
> >As there are some issues with the DisplayPort support, I went
> >though Rockchip's BSP kernel tree and looked for fixes. I found
> >two small changes for the initial register setup, which do not
> >help with the DP issue but seem sensible in general. Afterwards
> >I added one more fix, which corrects an issue that effectively
> >results in USB-C adapters with combined USB3+DP capabilities
> >not being able to use the DP part.
> >
> >Afterwards I added one more patch adding single-lane DP support
> >(found in Rockchip BSP kernel) and a couple of cleanups from my
> >side. These are logically independent from the fixes, but I put
> >all together in a single series because they need to be applied
> >in the right order to avoid conflicts.
> >
> >Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> >---
> >Frank Wang (1):
> > phy: rockchip: usbdp: Amend SSC modulation deviation
> >
> >Sebastian Reichel (4):
> > phy: rockchip: usbdp: Add missing mode_change update
> > phy: rockchip: usbdp: Rename DP lane functions
> > phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST
> > phy: rockchip: usbdp: Cleanup DP lane selection function
> >
> >William Wu (1):
> > phy: rockchip: usbdp: Fix LFPS detect threshold control
> >
> >Zhang Yubing (1):
> > phy: rockchip: usbdp: Support single-lane DP
> >
> > drivers/phy/rockchip/phy-rockchip-usbdp.c | 114 +++++++++++++-----------------
> > 1 file changed, 48 insertions(+), 66 deletions(-)
>
> After applying this series of patches, the hub that previously
> couldn’t recognize Alt Mode can now detect it and work properly,
> but it also triggers a USB-related SERR — did I miss something？
I thought this was from a different patch that I needed to get DP
working. I've spent the last week debugging this and I'm just about
to send v2 with a workaround. FWIW the SError is not introduced by
this series, but before it was much harder to run into it.
Greetings,
-- Sebastian
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] scsi: ufs: qcom,sc7180-ufshc: dt-bindings: Document the Milos UFS Controller
From: Luca Weiss @ 2026-02-13 14:08 UTC (permalink / raw)
To: Luca Weiss, Martin K. Petersen, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Alim Akhtar, Avri Altman, Bart Van Assche, Vinod Koul,
Neil Armstrong, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Krzysztof Kozlowski
In-Reply-To: <20260112-milos-ufs-v2-2-d3ce4f61f030@fairphone.com>
Hi Martin,
On Mon Jan 12, 2026 at 2:53 PM CET, Luca Weiss wrote:
> Document the UFS Controller on the Milos SoC.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
I've added you to this email now since you seem to pick up most patches
for these files. Could you take this one please to unblock Milos UFS
dts?
And maybe you could add yourself to MAINTAINERS so b4 picks up your
email for patches to these files?
Regards
Luca
> ---
> Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
> index d94ef4e6b85a..c85f126e52a0 100644
> --- a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
> +++ b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
> @@ -15,6 +15,7 @@ select:
> compatible:
> contains:
> enum:
> + - qcom,milos-ufshc
> - qcom,msm8998-ufshc
> - qcom,qcs8300-ufshc
> - qcom,sa8775p-ufshc
> @@ -33,6 +34,7 @@ properties:
> compatible:
> items:
> - enum:
> + - qcom,milos-ufshc
> - qcom,msm8998-ufshc
> - qcom,qcs8300-ufshc
> - qcom,sa8775p-ufshc
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: ti: j721e-wiz: Fix device node reference leak in wiz_get_lane_phy_types()
From: Vladimir Oltean @ 2026-02-13 10:46 UTC (permalink / raw)
To: Markus Elfring
Cc: Felix Gu, linux-phy, Jyri Sarha, Kishon Vijay Abraham I,
Neil Armstrong, Vinod Koul, LKML, kernel-janitors
In-Reply-To: <ffafec42-8d5f-429a-92b5-1b92c7643642@web.de>
On Fri, Feb 13, 2026 at 09:09:55AM +0100, Markus Elfring wrote:
> …
> > ---
> > Changes in v2:
> > - Use of_node_put() suggested by Vladimir Oltean.
> > - Link to v1: https://lore.kernel.org/r/20260211-wiz-v1-1-fdd018d02f33@gmail.com
> > ---
> > drivers/phy/ti/phy-j721e-wiz.c | 2 ++
> …
>
> * Would you like to complete the exception handling by using another goto chain?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.19#n526
While gotos have their place, here it seems simpler not to use them.
Felix would have needed to move the "int ret" variable from the
for_each_child_of_node_scoped() scope to the function scope, and
initialize it with 0. All that is unnecessary complexity here.
> * How do you think about to increase the application of scope-based resource management
> by additional update steps?
> https://elixir.bootlin.com/linux/v6.19-rc5/source/include/linux/cleanup.h#L157-L161
The cleanup.h API does not exist in all kernels where this bug fix can
be backported.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: ti: j721e-wiz: Fix device node reference leak in wiz_get_lane_phy_types()
From: Vladimir Oltean @ 2026-02-13 10:47 UTC (permalink / raw)
To: Felix Gu
Cc: Vinod Koul, Neil Armstrong, Kishon Vijay Abraham I, Jyri Sarha,
linux-phy, linux-kernel, Markus Elfring
In-Reply-To: <20260212-wiz-v2-1-6e8bd4cc7a4a@gmail.com>
On Thu, Feb 12, 2026 at 06:39:19PM +0800, Felix Gu wrote:
> The serdes device_node is obtained using of_get_child_by_name(),
> which increments the reference count. However, it is never put,
> leading to a reference leak.
>
> Add the missing of_node_put() calls to ensure the reference count is
> properly balanced.
>
> Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver")
> Suggested-by: Vladimir Oltean <olteanv@gmail.com>
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> Changes in v2:
> - Use of_node_put() suggested by Vladimir Oltean.
> - Link to v1: https://lore.kernel.org/r/20260211-wiz-v1-1-fdd018d02f33@gmail.com
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/3] phy: qcom: edp: Add per-version LDO configuration callback
From: Konrad Dybcio @ 2026-02-13 11:14 UTC (permalink / raw)
To: Yongxing Mou, Vinod Koul, Neil Armstrong, Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <8dbc18a0-6a64-491b-84b0-ba220c9050ac@oss.qualcomm.com>
On 2/12/26 10:04 AM, Yongxing Mou wrote:
>
>
> On 2/6/2026 6:52 PM, Konrad Dybcio wrote:
>> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>>> Introduce the com_ldo_config callback to support per‑PHY LDO
>>> configuration.
>>>
>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> +static int qcom_edp_ldo_config_v4(const struct qcom_edp *edp)
>>> +{
>>> + const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
>>> + u32 ldo_config;
>>> +
>>> + if (!edp->is_edp)
>>> + ldo_config = 0x0;
>>> + else if (dp_opts->link_rate <= 2700)
>>> + ldo_config = 0xC1;
>>
>> lowercase hex, please
>>
>>> + else
>>> + ldo_config = 0x81;
>>> +
>>> + writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
>>> + writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
>>
>> tx1 should be dp_ops->lanes ? 2 : ldo_config : 0x00, in all cases,
>> I believe
>>
>> Konrad
> Hi, here i want to confirm again.. In the HPG main link brinup sequence, it not say write TX0/TX1 ldo_config based on the lane count. Only when we switch the lane mode, the LDO config will be updated according to the lane count. so here do we really need this condition?
I don't believe these two cases are differentiated in your patch, unless
you're trying to say that the hardware is smart enough to turn off the LDO
for TX23 on its own as we switch modes, which I wouldn't bet it is and can't
find confirmation for
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/3] phy: qcom: edp: Correct and clean up eDP/DP combo PHY configuration values
From: Konrad Dybcio @ 2026-02-13 11:08 UTC (permalink / raw)
To: Yongxing Mou, Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <92556aa2-607f-4743-a480-19458836fffa@oss.qualcomm.com>
On 2/9/26 10:00 AM, Yongxing Mou wrote:
>
>
> On 2/6/2026 6:47 PM, Konrad Dybcio wrote:
>> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>>> According to the current HPG settings, most eDP/DP combo PHYs can reuse the
>>> same configuration values.
>>
>> Even across the various process nodes?
>>
> Emm,Currently, I have only checked the five platforms that already have eDP PHY driver support enabled. The results are the same as stated in the commit message: in DP mode and in eDP low‑vdiff mode, there are four platforms that can reuse the same settings. The HPG I used was the one I found on IPCAT. Regarding HRG, please move to next comment.
>>> DP mode：
>>> -sa8775p/sc7280/sc8280xp/x1e80100
>>> -glymur
>>> eDP mode(low vdiff):
>>> -glymur/sa8775p/sc8280xp/x1e80100
>>> -sc7280
>>> The current driver still keeps multiple versions of these tables and
>>> doesn't fully support every combo PHY mode. This patch removes the
>>> redundant configs and keeps only the sets we actually use, matching the
>>> platforms listed above.
>>
>> I see that e.g. eDP Low-Vdiff swing setting for RBR is:
>>
> Hi, do you mean emphasis settings, i don't see 0x11 0x12 in arr[0][1].
>> hamoa kodiak
>> arr[0][1] 0x11 0x12
>>
>> It may be that this changed later during tuning but it's not reflected
>> in the docs for kodiak
> Emm, if that, where can i get the correct value for tables.. In this patch, I’m indeed quite curious why the values before the modification differ from those in the HPG. I’m not sure about the reason. The HPG I used was taken directly from the current go/ipcat. Could you tell me where I can obtain the final table that should be used?
I.. wanted to ask you the same question..
I would assume that there's 3 possibilities:
a) the values have changed as they do during platform maturity
b) someone used the wrong values from the docs
c) someone downstream kernel as reference and that had wrong / older values
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/3] phy: qcom: edp: Add eDP phy mode switch support
From: Konrad Dybcio @ 2026-02-13 11:06 UTC (permalink / raw)
To: Yongxing Mou, Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <845165e6-4595-41de-8cff-d065e8f6b6be@oss.qualcomm.com>
On 2/10/26 11:29 AM, Yongxing Mou wrote:
>
>
> On 2/6/2026 7:02 PM, Konrad Dybcio wrote:
>> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>>> Add DP/eDP switch support by splitting the PHY swing/pre-emphasis tables
>>> into separate DP and eDP configurations. This allows the driver to select
>>> the correct table based on the is_edp flag.
>>>
>>> Add a dedicated table for the SC7280/glymur platforms, as they are not
>>> compatible with the others.
>>>
>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> +static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
>>> + { 0x0b, 0x11, 0x16, 0x1b },
>>> + { 0x0b, 0x19, 0x1f, 0xff },
>>> + { 0x18, 0x1f, 0xff, 0xff },
>>> + { 0x1f, 0xff, 0xff, 0xff }
>>> +};
>>> +
>>> +static const u8 edp_pre_emp_hbr2_hbr3_v3[4][4] = {
>>> + { 0x0c, 0x15, 0x19, 0x1e },
>>> + { 0x09, 0x14, 0x19, 0xff },
>>> + { 0x0f, 0x14, 0xff, 0xff },
>>> + { 0x0d, 0xff, 0xff, 0xff }
>>> +};
>>
>> This is not quite in line with docs for kodiak. Now, if you have
>> better/newer sequences than the HPG, I'm not objecting, but please
>> cross-check
>>
>> the rest of this patch I think looks fine
>>
>> Konrad
> Thanks for point that..
>>> +static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
>>> + { 0x0b, 0x11, 0x16, 0x1b },
> here should be { 0x06, 0x11, 0x16, 0x1b }, arr[0][1]: 0x0b->0x06
> does this looks fine? will check tables again..
For kodiak I see:
eDP HBR23 / low vdiff:
swing
0x0b, 0x11, 0x17, 0x1c
0x10, 0x19, 0x1f
0x19, 0x1f
0x1f
preemp
0x0c, 0x15, 0x19, 0x1e
0x08, 0x15, 0x19
0x0e, 0x14
0x0d
(notice how that mostly differs by the lowest bit being (not)set vs
your proposal)
eDP HBR23 / high vdiff:
swing
0x0a, 0x11, 0x17, 0x1f
0x0c, 0x14, 0x1d
0x15, 0x1f
0x17
preemp
0x08, 0x11, 0x17, 0x1b
0x00, 0x0c, 0x13
0x05, 0x10,
0x00
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Johan Hovold @ 2026-02-13 10:45 UTC (permalink / raw)
To: Loic Poulain
Cc: vkoul, kishon, linux-arm-msm, linux-phy, dmitry.baryshkov,
neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <CAFEp6-3yk3sPXj+hGuWvAFsFJAXjH4kWLV8k_5_v9Hax0XxaOg@mail.gmail.com>
On Fri, Feb 13, 2026 at 10:45:32AM +0100, Loic Poulain wrote:
> On Fri, Feb 13, 2026 at 10:07 AM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> > > Enabling runtime PM before attaching the hsphy instance as driver data
> > > can lead to a NULL pointer dereference in runtime PM callbacks that
> > > expect valid driver data. There is a small window where the suspend
> > > callback may run after PM runtime enabling and before runtime forbid.
> >
> > So here too, the commit should reflect that this cannot really happen in
> > practice.
>
> This happened in practice in the qcom‑qusb2 PHY driver, with the same
> code flow.
> Bug: https://github.com/qualcomm-linux/qcom-deb-images/issues/208
> Patch: https://lore.kernel.org/linux-arm-msm/20251219085640.114473-1-loic.poulain@oss.qualcomm.com/
Thanks for the link.
> I know it may sound unlikely, but this crash has been reported
> several times during boot‑stress testing. I haven’t investigated
> deeply enough to determine whether it’s caused by an unfortunate
> preemption window or a racing CPU.
But I'm literally asking for *what* would trigger the suspend in that
initial window between enable() and forbid() cause I don't see it.
A racing user space daemon re-enabling runtime PM after forbid() is
the only thing I can think of that could trigger this.
Johan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-02-13 9:45 UTC (permalink / raw)
To: Johan Hovold
Cc: vkoul, kishon, linux-arm-msm, linux-phy, dmitry.baryshkov,
neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <aY7pvakkOnaYsd5p@hovoldconsulting.com>
Hi Johan,
On Fri, Feb 13, 2026 at 10:07 AM Johan Hovold <johan@kernel.org> wrote:
>
> On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> > Enabling runtime PM before attaching the hsphy instance as driver data
> > can lead to a NULL pointer dereference in runtime PM callbacks that
> > expect valid driver data. There is a small window where the suspend
> > callback may run after PM runtime enabling and before runtime forbid.
>
> So here too, the commit should reflect that this cannot really happen in
> practice.
This happened in practice in the qcom‑qusb2 PHY driver, with the same
code flow.
Bug: https://github.com/qualcomm-linux/qcom-deb-images/issues/208
Patch: https://lore.kernel.org/linux-arm-msm/20251219085640.114473-1-loic.poulain@oss.qualcomm.com/
I know it may sound unlikely, but this crash has been reported
several times during boot‑stress testing. I haven’t investigated
deeply enough to determine whether it’s caused by an unfortunate
preemption window or a racing CPU.
I thought the series was already fairly conservative in its wording.
The titles use terms like “possible” and “unnecessary” to qualify the
crashes or unintended events. I can switch to “unlikely” if that
better characterizes the situation, but the issue isn’t purely
hypothetical.
Regards,
Loic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Johan Hovold @ 2026-02-13 9:07 UTC (permalink / raw)
To: Loic Poulain
Cc: vkoul, kishon, linux-arm-msm, linux-phy, dmitry.baryshkov,
neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <20260205160240.748371-6-loic.poulain@oss.qualcomm.com>
On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> Enabling runtime PM before attaching the hsphy instance as driver data
> can lead to a NULL pointer dereference in runtime PM callbacks that
> expect valid driver data. There is a small window where the suspend
> callback may run after PM runtime enabling and before runtime forbid.
So here too, the commit should reflect that this cannot really happen in
practice.
> Attach the hsphy instance as driver data before enabling runtime PM to
> prevent NULL pointer dereference in runtime PM callbacks.
>
> Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a
> short window where an unnecessary runtime suspend can occur.
>
> Use the devres-managed version to ensure PM runtime is symmetrically
> disabled during driver removal for proper cleanup.
>
> Fixes: 0d75f508a9d5 ("phy: qcom-snps: Add runtime suspend and resume handlers")
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Johan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 3/5] phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend
From: Johan Hovold @ 2026-02-13 9:02 UTC (permalink / raw)
To: Loic Poulain
Cc: vkoul, kishon, linux-arm-msm, linux-phy, dmitry.baryshkov,
neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <20260205160240.748371-4-loic.poulain@oss.qualcomm.com>
On Thu, Feb 05, 2026 at 05:02:38PM +0100, Loic Poulain wrote:
> 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) {`
So here too, what would trigger a suspend in this window? (Except
possibly user space disabling and reenabling runtime pm, which can't
happen in practice).
> This can also happen if user re-enables runtime-pm via the sysfs
> attribute before qmp phy is initialized.
This I guess can happen in theory, but you'd need to try pretty hard.
But I think the commit message should better reflect this is all mostly
theoretical (currently it sounds like something you've actually hit).
Johan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox