* Re: [PATCH phy-next] phy: apple: apple: Check the actual ioremap return value
From: Janne Grunau @ 2026-02-15 7:58 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Sven Peter, Neal Gompa, Vinod Koul, Neil Armstrong, Philipp Zabel,
asahi, linux-phy, linux-kernel, Dan Carpenter
In-Reply-To: <20260210204822.jr22el4rlyosin2q@skbuf>
Hej Vladimir,
On Tue, Feb 10, 2026 at 10:48:22PM +0200, Vladimir Oltean wrote:
> Hello Janne,
>
> On Sat, Feb 07, 2026 at 05:40:34PM +0100, Janne Grunau wrote:
> > The address where the devm_ioremap_resource() return value is stored is
> > always a valid pointer. Check the actual return value instead as that
> > that might be an error value.
> >
> > Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> > Closes: https://lore.kernel.org/asahi/aYXvX1bYOXtYCgfC@stanley.mountain/
> > Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY")
> > Signed-off-by: Janne Grunau <j@jannau.net>
> > ---
> > drivers/phy/apple/atc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/phy/apple/atc.c b/drivers/phy/apple/atc.c
> > index dc867f368b68748ea953e594ad998d7f965d8d1d..c144e273a555a741b49adfccbe046df83d193e03 100644
> > --- a/drivers/phy/apple/atc.c
> > +++ b/drivers/phy/apple/atc.c
> > @@ -2206,7 +2206,7 @@ static int atcphy_map_resources(struct platform_device *pdev, struct apple_atcph
> > for (int i = 0; i < ARRAY_SIZE(resources); i++) {
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM, resources[i].name);
> > *resources[i].addr = devm_ioremap_resource(&pdev->dev, res);
> > - if (IS_ERR(resources[i].addr))
> > + if (IS_ERR(*resources[i].addr))
> > return dev_err_probe(atcphy->dev, PTR_ERR(resources[i].addr),
> > "Unable to map %s regs", resources[i].name);
>
> This does not seem correct - every call site that tests a pointer for
> IS_ERR() also decodes the error using PTR_ERR(). Whereas you are here
> creating the pattern "if (IS_ERR(*a)) return PTR_ERR(a)".
missed this.
> Proven practice seems to tell us that insisting to save the
> devm_ioremap_resource() return code directly in *resources[i].addr
> is too complex here.
>
> Would you consider creating a temporary "void __iomem *addr" local
> variable, and set "*resources[i].addr = addr" only once it's validated?
> This would make the code obviously correct upon review.
I agree. A local variable makes this easier to read. Thanks for spotting
this and the suggestion. I'll change that for v2.
Janne
--
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-15 5:48 UTC (permalink / raw)
To: Vladimir Oltean
Cc: 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, linux-phy, devicetree, linux-kernel, linux-omap
In-Reply-To: <20260213190054.ezblztj3blmhtywr@skbuf>
On 14-02-2026 00:30, Vladimir Oltean wrote:
> Hi Charan,
>
> On Fri, Feb 13, 2026 at 10:06:16PM +0530, Charan Pedumuru wrote:
>> 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.
>
> If there was any request formulated to Vinod to pick up patch 1, then I
> also missed it while reading this series.
>
> Usually, dt-bindings patches are picked up by the subsystem maintainer
> while DTS patches are picked up by the platform maintainer. If you know
> that there is any dependency then it would greatly help if you could
> mention that upfront, or even specify how you expect the patches to be
> merged.
>
> In this case, I expect the warnings will get eventually resolved when
> Kevin picks up patch 1.
Yes.
>
> To avoid warnings from being introduced in the first place, you could
> have
> - requested all patches to be taken through a single tree (requires
> maintainer coordination with ACK from the other one, more complicated
> if the files touched are under heavy development)
> - requested a stable tag from the first maintainer, to be pulled in the
> second tree
> - send patch 1, wait for a merge window to pass, send patches 2-3
Sure, next time I will follow this procedure. Thanks.
--
Best Regards,
Charan.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 3/3] phy: k1-usb: k3: add USB2 PHY support
From: Yixun Lan @ 2026-02-14 12:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan
In-Reply-To: <20260214-11-k3-usb2-phy-v2-0-6ed31e031ab4@kernel.org>
Add USB2 PHY support for SpacemiT K3 SoC.
Register layout of handling USB disconnect operation has been changed,
So introducing a platform data to distinguish the different SoCs.
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
drivers/phy/spacemit/phy-k1-usb2.c | 34 +++++++++++++++++++++++++++++-----
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/spacemit/phy-k1-usb2.c b/drivers/phy/spacemit/phy-k1-usb2.c
index 959bf79c7a72..b4ba97481ddd 100644
--- a/drivers/phy/spacemit/phy-k1-usb2.c
+++ b/drivers/phy/spacemit/phy-k1-usb2.c
@@ -51,6 +51,9 @@
#define PHY_K1_HS_HOST_DISC 0x40
#define PHY_K1_HS_HOST_DISC_CLR BIT(0)
+#define PHY_K3_HS_HOST_DISC 0x20
+#define PHY_K3_HS_HOST_DISC_CLR BIT(8)
+
#define PHY_PLL_DIV_CFG 0x98
#define PHY_FDIV_FRACT_8_15 GENMASK(7, 0)
#define PHY_FDIV_FRACT_16_19 GENMASK(11, 8)
@@ -145,7 +148,7 @@ static int spacemit_usb2phy_exit(struct phy *phy)
return 0;
}
-static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
+static int spacemit_k1_usb2phy_disconnect(struct phy *phy, int port)
{
struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
@@ -155,10 +158,27 @@ static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
return 0;
}
-static const struct phy_ops spacemit_usb2phy_ops = {
+static int spacemit_k3_usb2phy_disconnect(struct phy *phy, int port)
+{
+ struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
+
+ regmap_update_bits(sphy->regmap_base, PHY_K3_HS_HOST_DISC,
+ PHY_K3_HS_HOST_DISC_CLR, PHY_K3_HS_HOST_DISC_CLR);
+
+ return 0;
+}
+
+static const struct phy_ops spacemit_k1_usb2phy_ops = {
.init = spacemit_usb2phy_init,
.exit = spacemit_usb2phy_exit,
- .disconnect = spacemit_usb2phy_disconnect,
+ .disconnect = spacemit_k1_usb2phy_disconnect,
+ .owner = THIS_MODULE,
+};
+
+static const struct phy_ops spacemit_k3_usb2phy_ops = {
+ .init = spacemit_usb2phy_init,
+ .exit = spacemit_usb2phy_exit,
+ .disconnect = spacemit_k3_usb2phy_disconnect,
.owner = THIS_MODULE,
};
@@ -167,12 +187,15 @@ static int spacemit_usb2phy_probe(struct platform_device *pdev)
struct phy_provider *phy_provider;
struct device *dev = &pdev->dev;
struct spacemit_usb2phy *sphy;
+ const struct phy_ops *ops;
void __iomem *base;
sphy = devm_kzalloc(dev, sizeof(*sphy), GFP_KERNEL);
if (!sphy)
return -ENOMEM;
+ ops = device_get_match_data(dev);
+
sphy->clk = devm_clk_get_prepared(&pdev->dev, NULL);
if (IS_ERR(sphy->clk))
return dev_err_probe(dev, PTR_ERR(sphy->clk), "Failed to get clock\n");
@@ -185,7 +208,7 @@ static int spacemit_usb2phy_probe(struct platform_device *pdev)
if (IS_ERR(sphy->regmap_base))
return dev_err_probe(dev, PTR_ERR(sphy->regmap_base), "Failed to init regmap\n");
- sphy->phy = devm_phy_create(dev, NULL, &spacemit_usb2phy_ops);
+ sphy->phy = devm_phy_create(dev, NULL, ops);
if (IS_ERR(sphy->phy))
return dev_err_probe(dev, PTR_ERR(sphy->phy), "Failed to create phy\n");
@@ -196,7 +219,8 @@ static int spacemit_usb2phy_probe(struct platform_device *pdev)
}
static const struct of_device_id spacemit_usb2phy_dt_match[] = {
- { .compatible = "spacemit,k1-usb2-phy", },
+ { .compatible = "spacemit,k1-usb2-phy", .data = &spacemit_k1_usb2phy_ops },
+ { .compatible = "spacemit,k3-usb2-phy", .data = &spacemit_k3_usb2phy_ops },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, spacemit_usb2phy_dt_match);
--
2.52.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/3] phy: k1-usb: add disconnect function support
From: Yixun Lan @ 2026-02-14 12:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan
In-Reply-To: <20260214-11-k3-usb2-phy-v2-0-6ed31e031ab4@kernel.org>
A disconnect status BIT of USB2 PHY need to be cleared, otherwise
it will fail to work properly during next connection when devices
connect to roothub directly.
Fixes: fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
drivers/phy/spacemit/phy-k1-usb2.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/phy/spacemit/phy-k1-usb2.c b/drivers/phy/spacemit/phy-k1-usb2.c
index 342061380012..959bf79c7a72 100644
--- a/drivers/phy/spacemit/phy-k1-usb2.c
+++ b/drivers/phy/spacemit/phy-k1-usb2.c
@@ -48,6 +48,9 @@
#define PHY_CLK_HSTXP_EN BIT(3) /* clock hstxp enable */
#define PHY_HSTXP_MODE BIT(4) /* 0: force en_txp to be 1; 1: no force */
+#define PHY_K1_HS_HOST_DISC 0x40
+#define PHY_K1_HS_HOST_DISC_CLR BIT(0)
+
#define PHY_PLL_DIV_CFG 0x98
#define PHY_FDIV_FRACT_8_15 GENMASK(7, 0)
#define PHY_FDIV_FRACT_16_19 GENMASK(11, 8)
@@ -142,9 +145,20 @@ static int spacemit_usb2phy_exit(struct phy *phy)
return 0;
}
+static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
+{
+ struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
+
+ regmap_update_bits(sphy->regmap_base, PHY_K1_HS_HOST_DISC,
+ PHY_K1_HS_HOST_DISC_CLR, PHY_K1_HS_HOST_DISC_CLR);
+
+ return 0;
+}
+
static const struct phy_ops spacemit_usb2phy_ops = {
.init = spacemit_usb2phy_init,
.exit = spacemit_usb2phy_exit,
+ .disconnect = spacemit_usb2phy_disconnect,
.owner = THIS_MODULE,
};
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: phy: spacemit: k3: add USB2 PHY support
From: Yixun Lan @ 2026-02-14 12:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Krzysztof Kozlowski
In-Reply-To: <20260214-11-k3-usb2-phy-v2-0-6ed31e031ab4@kernel.org>
Introduce a compatible string for the USB2 PHY in SpacemiT K3 SoC. The IP
of USB2 PHY mostly shares the same functionalities with K1 SoC, while has
some register layout changes.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
index 43eaca90d88c..18025e5f60d6 100644
--- a/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
@@ -4,14 +4,16 @@
$id: http://devicetree.org/schemas/phy/spacemit,usb2-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SpacemiT K1 SoC USB 2.0 PHY
+title: SpacemiT K1/K3 SoC USB 2.0 PHY
maintainers:
- Ze Huang <huang.ze@linux.dev>
properties:
compatible:
- const: spacemit,k1-usb2-phy
+ enum:
+ - spacemit,k1-usb2-phy
+ - spacemit,k3-usb2-phy
reg:
maxItems: 1
--
2.52.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/3] phy: spacemit: Add USB2 PHY support for K3 SoC
From: Yixun Lan @ 2026-02-14 12:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Krzysztof Kozlowski
The series trys to add USB2 PHY support for SpacemiT K3 SoC,
while patch [2/3] implement a disconnect function which is
needed during next connection.
No DTS part has been inclueded in this series, instead I plan
to submit while adding USB host support.
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
Changes in v2:
- collect ACK
- add Fixes tag
- implement separate phy_ops
- Link to v1: https://lore.kernel.org/r/20260212-11-k3-usb2-phy-v1-0-43578592405d@kernel.org
---
Yixun Lan (3):
dt-bindings: phy: spacemit: k3: add USB2 PHY support
phy: k1-usb: add disconnect function support
phy: k1-usb: k3: add USB2 PHY support
.../devicetree/bindings/phy/spacemit,usb2-phy.yaml | 6 ++-
drivers/phy/spacemit/phy-k1-usb2.c | 44 ++++++++++++++++++++--
2 files changed, 45 insertions(+), 5 deletions(-)
---
base-commit: dd39930f3d9c1d74a40b79d368e1f3d1555e919c
change-id: 20260124-11-k3-usb2-phy-c4630b990b1f
Best regards,
--
Yixun Lan <dlan@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/6] arm64: dts: qcom: milos: Add UFS nodes
From: Dmitry Baryshkov @ 2026-02-13 21:06 UTC (permalink / raw)
To: Abel Vesa
Cc: Luca Weiss, 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, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, linux-crypto, devicetree, linux-kernel, linux-scsi,
linux-phy, Konrad Dybcio
In-Reply-To: <7zdyb2wnojudnrnomnx4aiwvni3e6i52kfioflb3gslztsizkw@ofvvkvrv5f3s>
On Tue, Jan 20, 2026 at 04:52:43PM +0200, Abel Vesa wrote:
> On 26-01-20 16:49:26, Abel Vesa wrote:
> > On 26-01-12 14:53:18, Luca Weiss wrote:
> > > Add the nodes for the UFS PHY and UFS host controller, along with the
> > > ICE used for UFS.
> > >
> > > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/milos.dtsi | 129 +++++++++++++++++++++++++++++++++++-
> > > 1 file changed, 126 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> > > index e1a51d43943f..7c8a84bfaee1 100644
> > > --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> > > @@ -1151,6 +1151,129 @@ aggre2_noc: interconnect@1700000 {
> > > qcom,bcm-voters = <&apps_bcm_voter>;
> > > };
> > >
> > > + ufs_mem_phy: phy@1d80000 {
> > > + compatible = "qcom,milos-qmp-ufs-phy";
> > > + reg = <0x0 0x01d80000 0x0 0x2000>;
> > > +
> > > + clocks = <&rpmhcc RPMH_CXO_CLK>,
> > > + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
> > > + <&tcsr TCSR_UFS_CLKREF_EN>;
> > > + clock-names = "ref",
> > > + "ref_aux",
> > > + "qref";
> > > +
> > > + resets = <&ufs_mem_hc 0>;
> > > + reset-names = "ufsphy";
> > > +
> > > + power-domains = <&gcc UFS_MEM_PHY_GDSC>;
> > > +
> > > + #clock-cells = <1>;
> > > + #phy-cells = <0>;
> > > +
> > > + status = "disabled";
> > > + };
> > > +
> > > + ufs_mem_hc: ufshc@1d84000 {
> > > + compatible = "qcom,milos-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
> > > + reg = <0x0 0x01d84000 0x0 0x3000>;
> > > +
> > > + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH 0>;
> > > +
> > > + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
> > > + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
> > > + <&gcc GCC_UFS_PHY_AHB_CLK>,
> > > + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
> > > + <&tcsr TCSR_UFS_PAD_CLKREF_EN>,
> >
> > Maybe I'm looking at the wrong documentation, but it doesn't seem to exist
> > such clock on Milos. It does exist on SM8650 though. So maybe the TCSR CC
> > driver is not really that much compatible between these two platforms.
> >
> > I take it that the UFS works. Maybe because the actual TCSR UFS clkref
> > is left enabled at boot?
>
> Oh, nevemind. I think I was looking at the wrong SoC.
Is that an r-b then? ;-)
--
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: Vladimir Oltean @ 2026-02-13 20:15 UTC (permalink / raw)
To: Loic Poulain
Cc: Johan Hovold, vkoul, kishon, linux-arm-msm, linux-phy,
dmitry.baryshkov, neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <CAFEp6-0rzkqc0ajN72q=mv3U-TT0JHMSPmnJD6ohKuLmbPz2-A@mail.gmail.com>
Hello Loic,
On Fri, Feb 13, 2026 at 04:04:43PM +0100, Loic Poulain wrote:
> 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'.
Please resend this patch with the commit message including this
explanation (note that your code snippet from __driver_probe_device() is
missing a relevant call to pm_runtime_get_suppliers()).
Also, please separate the devres change to its own patch. It is fixing a
different logical issue (missing pm_runtime_disable() causes device with
unbound driver to have non-zero dev->power.disable_depth; should warn on
driver re-probe).
Another comment upon reviewing this driver's runtime PM use (although
this is at most something that may result in a patch for "next"):
This driver uses hsphy->phy_initialized to make sure qcom_snps_hsphy_suspend()
isn't called unless qcom_snps_hsphy_init() was called.
Don't we achieve the same behaviour by replacing "hsphy->phy_initialized = true"
with pm_runtime_get_sync(dev) and "hsphy->phy_initialized = false" with
pm_runtime_put(dev)?
--
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: Vladimir Oltean @ 2026-02-13 19:00 UTC (permalink / raw)
To: Charan Pedumuru
Cc: 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, linux-phy, devicetree, linux-kernel, linux-omap
In-Reply-To: <f60156a6-58af-4548-9dc3-71c71b822343@gmail.com>
Hi Charan,
On Fri, Feb 13, 2026 at 10:06:16PM +0530, Charan Pedumuru wrote:
> 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.
If there was any request formulated to Vinod to pick up patch 1, then I
also missed it while reading this series.
Usually, dt-bindings patches are picked up by the subsystem maintainer
while DTS patches are picked up by the platform maintainer. If you know
that there is any dependency then it would greatly help if you could
mention that upfront, or even specify how you expect the patches to be
merged.
In this case, I expect the warnings will get eventually resolved when
Kevin picks up patch 1.
To avoid warnings from being introduced in the first place, you could
have
- requested all patches to be taken through a single tree (requires
maintainer coordination with ACK from the other one, more complicated
if the files touched are under heavy development)
- requested a stable tag from the first maintainer, to be pulled in the
second tree
- send patch 1, wait for a merge window to pass, send patches 2-3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add vdda-refgen supplies for Glymur
From: Dmitry Baryshkov @ 2026-02-13 17:48 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <aY1KCLDDoQtLJ4F1@hu-qianyu-lv.qualcomm.com>
On Wed, Feb 11, 2026 at 07:33:28PM -0800, Qiang Yu wrote:
> On Mon, Feb 09, 2026 at 03:15:24PM +0200, Dmitry Baryshkov wrote:
> > On Sun, Feb 08, 2026 at 08:49:40PM -0800, Qiang Yu wrote:
> > > The refgen providing reference voltage for PCIe QMP PHY on Glymur requires
> > > two power supplies independent from the PHY's core and qref rails. Add
> > > support for vdda-refgen0p9 and vdda-refgen1p2 supplies with a dedicated
> > > glymur_qmp_phy_vreg_l list.
> > >
> > > Update both Gen5x4 and Gen4x2 configurations to use the new supply list.
> >
> > I'd ask for the DTSI patch too...
> >
> I will post dtsi patch after we get agreement on how to descibe refgen in
> dt-bindings.
Please include DT patches in future series, they help us understand your
changes.
>
> - Qiang Yu
> > >
> > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > ---
> > > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 12 ++++++++----
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> >
> > --
> > With best wishes
> > Dmitry
--
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 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
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