[PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5

[PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5

[Konrad Dybcio]

The MSM8996 QUSB2PHY was not being guaranteed a power source.
The SM6125's QUSB2PHY was believed to be idential as the 96 one. It
wasn't. This series tackles that, freeing us of some dt checker
errors about vdd-supply not found on MSM8996 boards.

Compile-tested only, but docs confirm my findings..

Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Konrad Dybcio (4):
      dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
      phy: qcom-qusb2: Fix SM6115 init sequence
      arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
      arm64: dts: qcom: sm6125: Fix QUSB2 compatible

 .../devicetree/bindings/phy/qcom,qusb2-phy.yaml    | 31 ++++++++++++++++++++--
 arch/arm64/boot/dts/qcom/msm8996.dtsi              | 10 +++++++
 arch/arm64/boot/dts/qcom/sm6125.dtsi               |  3 ++-
 drivers/phy/qualcomm/phy-qcom-qusb2.c              |  4 +--
 4 files changed, 43 insertions(+), 5 deletions(-)
---
base-commit: 49e02880ec0a8c378e811bc9d85da188d7c6204c
change-id: 20260610-topic-8996_61x5_qusb2phy-ad052b99e9de

Best regards,
--  
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

[PATCH 1/4] dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996

[Konrad Dybcio]

From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

SM6125 DT currently uses just the MSM8996 compatible (without a primary
SM6125-specific one). This is not only wrong for the reasons of
violating guidelines, but also happens to not be valid.

The MSM8996 PHY is quite similar, although it requies a different init
sequence (for arch reasons). MSM8996 also needs different power
plumbing, as the VDD supply is fed through VDD_MX (which we define as
a power domain rather than a regulator), unlike on SM6125.

The init sequence seems to have been "good enough", but now that the
bindings clearly diverge, add a new compatible for SM6125 with a SM6115
fallback (as they seem to be an exact match from the SW interface POV).

Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
 .../devicetree/bindings/phy/qcom,qusb2-phy.yaml    | 31 ++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index 39851ba9de43..807d64aee547 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -30,6 +30,9 @@ properties:
               - qcom,sdm660-qusb2-phy
               - qcom,sm4250-qusb2-phy
               - qcom,sm6115-qusb2-phy
+      - items:
+          - const: qcom,sm6125-qusb2-phy
+          - const: qcom,sm6115-qusb2-phy
       - items:
           - enum:
               - qcom,sc7180-qusb2-phy
@@ -57,6 +60,12 @@ properties:
       - const: ref
       - const: iface
 
+  power-domains:
+    maxItems: 1
+
+  required-opps:
+    maxItems: 1
+
   vdd-supply:
     description:
       Phandle to 0.9V regulator supply to PHY digital circuit.
@@ -160,7 +169,6 @@ required:
   - "#phy-cells"
   - clocks
   - clock-names
-  - vdd-supply
   - vdda-pll-supply
   - vdda-phy-dpdm-supply
   - resets
@@ -182,6 +190,22 @@ allOf:
         qcom,preemphasis-width: false
         qcom,hsdisc-trim-value: false
 
+  # On MSM8996, VDD is supplied via the MX power domain
+  - if:
+      properties:
+        compatible:
+          const: qcom,msm8996-qusb2-phy
+    then:
+      required:
+        - power-domains
+        - required-opps
+    else:
+      properties:
+        power-domains: false
+        required-opps: false
+      required:
+        - vdd-supply
+
 additionalProperties: false
 
 examples:
@@ -196,10 +220,13 @@ examples:
                  <&gcc GCC_RX1_USB2_CLKREF_CLK>;
         clock-names = "cfg_ahb", "ref";
 
-        vdd-supply = <&pm8994_l28>;
         vdda-pll-supply = <&pm8994_l12>;
         vdda-phy-dpdm-supply = <&pm8994_l24>;
 
         resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+
+        power-domains = <&rpmpd_mx>;
+        required-opps = <&rpmpd_opp4>;
+
         nvmem-cells = <&qusb2p_hstx_trim>;
     };

-- 
2.54.0

Re: [PATCH 1/4] dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996

[Krzysztof Kozlowski]

On Wed, Jun 10, 2026 at 02:04:14PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> SM6125 DT currently uses just the MSM8996 compatible (without a primary
> SM6125-specific one). This is not only wrong for the reasons of
> violating guidelines, but also happens to not be valid.
> 
> The MSM8996 PHY is quite similar, although it requies a different init
> sequence (for arch reasons). MSM8996 also needs different power
> plumbing, as the VDD supply is fed through VDD_MX (which we define as
> a power domain rather than a regulator), unlike on SM6125.
> 
> The init sequence seems to have been "good enough", but now that the
> bindings clearly diverge, add a new compatible for SM6125 with a SM6115
> fallback (as they seem to be an exact match from the SW interface POV).
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/phy/qcom,qusb2-phy.yaml    | 31 ++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

[PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence

[Konrad Dybcio]

From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

I don't know where the existing one came from, but it's apparently
wrong, according to both docs and a downstream DT [1]. Fix it up.

The updated values also happen to match SM6125, which will allow us
to fix that platform too.

[1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/bengal-usb.dtsi#145
Fixes: 7756f1d6369e ("phy: qcom-qusb2: Add configuration for SM4250 and SM6115")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index eb93015be841..c304ccd9f31f 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -233,9 +233,9 @@ static const struct qusb2_phy_init_tbl msm8998_init_tbl[] = {
 
 static const struct qusb2_phy_init_tbl sm6115_init_tbl[] = {
 	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0xf8),
-	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0x53),
+	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0xb3),
 	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE3, 0x81),
-	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE4, 0x17),
+	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE4, 0xc0),
 
 	QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_TUNE, 0x30),
 	QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL1, 0x79),

-- 
2.54.0

Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence

[Abel Vesa]

On 26-06-10 14:04:15, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> I don't know where the existing one came from, but it's apparently
> wrong, according to both docs and a downstream DT [1]. Fix it up.
> 
> The updated values also happen to match SM6125, which will allow us
> to fix that platform too.
> 
> [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/bengal-usb.dtsi#145
> Fixes: 7756f1d6369e ("phy: qcom-qusb2: Add configuration for SM4250 and SM6115")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence

[Dmitry Baryshkov]

On Wed, Jun 10, 2026 at 02:04:15PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> I don't know where the existing one came from, but it's apparently
> wrong, according to both docs and a downstream DT [1]. Fix it up.
> 
> The updated values also happen to match SM6125, which will allow us
> to fix that platform too.
> 
> [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/bengal-usb.dtsi#145
> Fixes: 7756f1d6369e ("phy: qcom-qusb2: Add configuration for SM4250 and SM6115")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence

[Iskren Chernev]

On 6/10/26 3:04 PM, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> I don't know where the existing one came from, but it's apparently
> wrong, according to both docs and a downstream DT [1]. Fix it up.

They came from DTB extracted from a running billie2 (OnePlus Nord N100):
[1] 
https://mainlining.dev/wp-content/uploads/2021/02/03_dtbdump_Qualcomm_Technologies_Inc._Bengal_SoC.dts 


The phone was bough early after launch, so it could have been 
wrong/updated later.

> The updated values also happen to match SM6125, which will allow us
> to fix that platform too.
> 
> [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/bengal-usb.dtsi#145
> Fixes: 7756f1d6369e ("phy: qcom-qusb2: Add configuration for SM4250 and SM6115")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
>   drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
> index eb93015be841..c304ccd9f31f 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
> @@ -233,9 +233,9 @@ static const struct qusb2_phy_init_tbl msm8998_init_tbl[] = {
>   
>   static const struct qusb2_phy_init_tbl sm6115_init_tbl[] = {
>   	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0xf8),
> -	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0x53),
> +	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0xb3),
>   	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE3, 0x81),
> -	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE4, 0x17),
> +	QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE4, 0xc0),
>   
>   	QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_TUNE, 0x30),
>   	QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL1, 0x79),
> 

Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence

[Konrad Dybcio]

On 6/14/26 2:29 PM, Iskren Chernev wrote:
> 
> 
> On 6/10/26 3:04 PM, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> I don't know where the existing one came from, but it's apparently
>> wrong, according to both docs and a downstream DT [1]. Fix it up.
> 
> They came from DTB extracted from a running billie2 (OnePlus Nord N100):
> [1] https://mainlining.dev/wp-content/uploads/2021/02/03_dtbdump_Qualcomm_Technologies_Inc._Bengal_SoC.dts
> 
> The phone was bough early after launch, so it could have been wrong/updated later.

Good to see you're still around!

Looks like vendor tuning. I see that even the initial commit for
6115 had the init sequence I posted. And the OnePlus sources have
what seems like a project-specific local copy of the DTSI:

https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/qcom/bengal-usb.dtsi#L145
https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/20882/bengal-usb.dtsi#L148

To support that, we should add a new property to override the TUNEx
registers - like e.g. qcom,hstx-trim-value that's already consumed

Would you like to look into that, or should I take this?

Konrad

Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence

[Iskren Chernev]

On 6/15/26 1:44 PM, Konrad Dybcio wrote:
> On 6/14/26 2:29 PM, Iskren Chernev wrote:
>>
>>
>> On 6/10/26 3:04 PM, Konrad Dybcio wrote:
>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>
>>> I don't know where the existing one came from, but it's apparently
>>> wrong, according to both docs and a downstream DT [1]. Fix it up.
>>
>> They came from DTB extracted from a running billie2 (OnePlus Nord N100):
>> [1] https://mainlining.dev/wp-content/uploads/2021/02/03_dtbdump_Qualcomm_Technologies_Inc._Bengal_SoC.dts
>>
>> The phone was bough early after launch, so it could have been wrong/updated later.
>
> Good to see you're still around!
>
> Looks like vendor tuning. I see that even the initial commit for
> 6115 had the init sequence I posted. And the OnePlus sources have
> what seems like a project-specific local copy of the DTSI:
>
> https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/qcom/bengal-usb.dtsi#L145
> https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/20882/bengal-usb.dtsi#L148
>
> To support that, we should add a new property to override the TUNEx
> registers - like e.g. qcom,hstx-trim-value that's already consumed

My 2 cents - I never understood why init sequences are taboo in mainline
and widely used in downstream. I guess if it doesn't change (but across
what and who decides) it should be in code, but if it's "tuning"
- whatever that means, possibly depends on other components around, it
should be "configurable" via DT.

> Would you like to look into that, or should I take this?

You can take it, the other option is to mark a TODO, and if somebody
feels strongly about the binary value in a usb tune register s/he can
take up the task.

I just wanted to point out that the number didn't come from a random
number generator (or AI).

> Konrad

Iskren

Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence

[Konrad Dybcio]

On 6/17/26 2:48 PM, Iskren Chernev wrote:
> 
> 
> On 6/15/26 1:44 PM, Konrad Dybcio wrote:
>> On 6/14/26 2:29 PM, Iskren Chernev wrote:
>>>
>>>
>>> On 6/10/26 3:04 PM, Konrad Dybcio wrote:
>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>
>>>> I don't know where the existing one came from, but it's apparently
>>>> wrong, according to both docs and a downstream DT [1]. Fix it up.
>>>
>>> They came from DTB extracted from a running billie2 (OnePlus Nord N100):
>>> [1] https://mainlining.dev/wp-content/uploads/2021/02/03_dtbdump_Qualcomm_Technologies_Inc._Bengal_SoC.dts
>>>
>>> The phone was bough early after launch, so it could have been wrong/updated later.
>>
>> Good to see you're still around!
>>
>> Looks like vendor tuning. I see that even the initial commit for
>> 6115 had the init sequence I posted. And the OnePlus sources have
>> what seems like a project-specific local copy of the DTSI:
>>
>> https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/qcom/bengal-usb.dtsi#L145
>> https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/20882/bengal-usb.dtsi#L148
>>
>> To support that, we should add a new property to override the TUNEx
>> registers - like e.g. qcom,hstx-trim-value that's already consumed
> 
> My 2 cents - I never understood why init sequences are taboo in mainline
> and widely used in downstream. I guess if it doesn't change (but across
> what and who decides) it should be in code, but if it's "tuning"
> - whatever that means, possibly depends on other components around, it
> should be "configurable" via DT.

The PHY has some electrical characteristics of its own, and then atop
that are the characteristics of what's on the other end of it. Making
all parameters configurable (i.e. raw init sequence) leads to duplication
and pure blob seqeuences, whereas making everything constant leads to
polluting the driver (if every device-specific seq was to be in C files)

I think the current model of "override as necessary" is OK, especially
since we can use the upstream leverage to require describing what the
altered parameters actually change

>> Would you like to look into that, or should I take this?
> 
> You can take it, the other option is to mark a TODO, and if somebody
> feels strongly about the binary value in a usb tune register s/he can
> take up the task.

Seems like OnePlus does.. actually, a number of vendors do. Sony
does/used to do some tuning there too.

> I just wanted to point out that the number didn't come from a random
> number generator (or AI).

I'm sorry if my language was too harsh. You used the best sources
you had and had no reason to believe they were not the expected values.

Konrad

[PATCH 3/4] arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs

[Konrad Dybcio]

From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

The QUSB2 PHYs are powered by (among others) the VDD_MX power rail.
Describe that in the DT.

Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 2f67e665996f..b7cd1928335c 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -3192,7 +3192,12 @@ hsusb_phy1: phy@7411000 {
 			clock-names = "cfg_ahb", "ref";
 
 			resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+
+			power-domains = <&rpmpd MSM8996_VDDMX>;
+			required-opps = <&rpmpd_opp4>;
+
 			nvmem-cells = <&qusb2p_hstx_trim>;
+
 			status = "disabled";
 		};
 
@@ -3206,7 +3211,12 @@ hsusb_phy2: phy@7412000 {
 			clock-names = "cfg_ahb", "ref";
 
 			resets = <&gcc GCC_QUSB2PHY_SEC_BCR>;
+
+			power-domains = <&rpmpd MSM8996_VDDMX>;
+			required-opps = <&rpmpd_opp4>;
+
 			nvmem-cells = <&qusb2s_hstx_trim>;
+
 			status = "disabled";
 		};
 

-- 
2.54.0

Re: [PATCH 3/4] arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs

[Dmitry Baryshkov]

On Wed, Jun 10, 2026 at 02:04:16PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> The QUSB2 PHYs are powered by (among others) the VDD_MX power rail.
> Describe that in the DT.
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 2f67e665996f..b7cd1928335c 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -3192,7 +3192,12 @@ hsusb_phy1: phy@7411000 {
>  			clock-names = "cfg_ahb", "ref";
>  
>  			resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
> +
> +			power-domains = <&rpmpd MSM8996_VDDMX>;
> +			required-opps = <&rpmpd_opp4>;

Interesting, might it be the reason for QUSB PLL locking issues which I
have been observing from time to time?

> +
>  			nvmem-cells = <&qusb2p_hstx_trim>;
> +
>  			status = "disabled";
>  		};
>  
> @@ -3206,7 +3211,12 @@ hsusb_phy2: phy@7412000 {
>  			clock-names = "cfg_ahb", "ref";
>  
>  			resets = <&gcc GCC_QUSB2PHY_SEC_BCR>;
> +
> +			power-domains = <&rpmpd MSM8996_VDDMX>;
> +			required-opps = <&rpmpd_opp4>;
> +
>  			nvmem-cells = <&qusb2s_hstx_trim>;
> +
>  			status = "disabled";
>  		};
>  
> 
> -- 
> 2.54.0
> 
> 
> -- 
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs

[Konrad Dybcio]

On 6/10/26 3:21 PM, Dmitry Baryshkov wrote:
> On Wed, Jun 10, 2026 at 02:04:16PM +0200, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> The QUSB2 PHYs are powered by (among others) the VDD_MX power rail.
>> Describe that in the DT.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> ---
>>  arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> index 2f67e665996f..b7cd1928335c 100644
>> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> @@ -3192,7 +3192,12 @@ hsusb_phy1: phy@7411000 {
>>  			clock-names = "cfg_ahb", "ref";
>>  
>>  			resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
>> +
>> +			power-domains = <&rpmpd MSM8996_VDDMX>;
>> +			required-opps = <&rpmpd_opp4>;
> 
> Interesting, might it be the reason for QUSB PLL locking issues which I
> have been observing from time to time?

Possibly. I'm surprised that this is such a high value (4 out of 7,
whatever that used to mean in the olden RPM SMD times, maybe NOM?)
but that's what msm-3.18 uses..

Konrad

[PATCH 4/4] arm64: dts: qcom: sm6125: Fix QUSB2 compatible

[Konrad Dybcio]

From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

There are a couple issues with the current description:

1) The msm8996 compatible is wholly reused, without a SM6125-specific
   primary compatible
2) MSM8996 has a different power setup (VDD powered through a RPMPD
   power-domain vs a regulator)
3) MSM8996 uses a different init sequence

As part of fixing all of them, use a SM6125-specific compatible with a
SM6115 fallback.

Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm6125.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi b/arch/arm64/boot/dts/qcom/sm6125.dtsi
index 6e84c226948c..688548cef0f1 100644
--- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
@@ -681,7 +681,8 @@ gcc: clock-controller@1400000 {
 		};
 
 		hsusb_phy1: phy@1613000 {
-			compatible = "qcom,msm8996-qusb2-phy";
+			compatible = "qcom,sm6125-qusb2-phy",
+				     "qcom,sm6115-qusb2-phy";
 			reg = <0x01613000 0x180>;
 			#phy-cells = <0>;
 

-- 
2.54.0

Re: [PATCH 4/4] arm64: dts: qcom: sm6125: Fix QUSB2 compatible

[Dmitry Baryshkov]

On Wed, Jun 10, 2026 at 02:04:17PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> There are a couple issues with the current description:
> 
> 1) The msm8996 compatible is wholly reused, without a SM6125-specific
>    primary compatible
> 2) MSM8996 has a different power setup (VDD powered through a RPMPD
>    power-domain vs a regulator)
> 3) MSM8996 uses a different init sequence
> 
> As part of fixing all of them, use a SM6125-specific compatible with a
> SM6115 fallback.
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/sm6125.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5

[Konrad Dybcio]

On 6/10/26 2:04 PM, Konrad Dybcio wrote:
> The MSM8996 QUSB2PHY was not being guaranteed a power source.
> The SM6125's QUSB2PHY was believed to be idential as the 96 one. It
> wasn't. This series tackles that, freeing us of some dt checker
> errors about vdd-supply not found on MSM8996 boards.
> 
> Compile-tested only, but docs confirm my findings..
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> Konrad Dybcio (4):
>       dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
>       phy: qcom-qusb2: Fix SM6115 init sequence
>       arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
>       arm64: dts: qcom: sm6125: Fix QUSB2 compatible
> 
>  .../devicetree/bindings/phy/qcom,qusb2-phy.yaml    | 31 ++++++++++++++++++++--
>  arch/arm64/boot/dts/qcom/msm8996.dtsi              | 10 +++++++
>  arch/arm64/boot/dts/qcom/sm6125.dtsi               |  3 ++-
>  drivers/phy/qualcomm/phy-qcom-qusb2.c              |  4 +--
>  4 files changed, 43 insertions(+), 5 deletions(-)
> ---

Note that msm8996pro may need even more looking into, but that's a
story for another day

Konrad

Re: [PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5

[Dmitry Baryshkov]

On Wed, Jun 10, 2026 at 02:49:31PM +0200, Konrad Dybcio wrote:
> On 6/10/26 2:04 PM, Konrad Dybcio wrote:
> > The MSM8996 QUSB2PHY was not being guaranteed a power source.
> > The SM6125's QUSB2PHY was believed to be idential as the 96 one. It
> > wasn't. This series tackles that, freeing us of some dt checker
> > errors about vdd-supply not found on MSM8996 boards.
> > 
> > Compile-tested only, but docs confirm my findings..
> > 
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > ---
> > Konrad Dybcio (4):
> >       dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
> >       phy: qcom-qusb2: Fix SM6115 init sequence
> >       arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
> >       arm64: dts: qcom: sm6125: Fix QUSB2 compatible
> > 
> >  .../devicetree/bindings/phy/qcom,qusb2-phy.yaml    | 31 ++++++++++++++++++++--
> >  arch/arm64/boot/dts/qcom/msm8996.dtsi              | 10 +++++++
> >  arch/arm64/boot/dts/qcom/sm6125.dtsi               |  3 ++-
> >  drivers/phy/qualcomm/phy-qcom-qusb2.c              |  4 +--
> >  4 files changed, 43 insertions(+), 5 deletions(-)
> > ---
> 
> Note that msm8996pro may need even more looking into, but that's a
> story for another day

JFYI, MSM8996 Pro is being used in the DRM / Mesa CI. If there is an
important difference, it would be nice to get it sorted out too.

-- 
With best wishes
Dmitry

Re: [PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5

[Konrad Dybcio]

On 6/10/26 3:03 PM, Dmitry Baryshkov wrote:
> On Wed, Jun 10, 2026 at 02:49:31PM +0200, Konrad Dybcio wrote:
>> On 6/10/26 2:04 PM, Konrad Dybcio wrote:
>>> The MSM8996 QUSB2PHY was not being guaranteed a power source.
>>> The SM6125's QUSB2PHY was believed to be idential as the 96 one. It
>>> wasn't. This series tackles that, freeing us of some dt checker
>>> errors about vdd-supply not found on MSM8996 boards.
>>>
>>> Compile-tested only, but docs confirm my findings..
>>>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>> ---
>>> Konrad Dybcio (4):
>>>       dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
>>>       phy: qcom-qusb2: Fix SM6115 init sequence
>>>       arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
>>>       arm64: dts: qcom: sm6125: Fix QUSB2 compatible
>>>
>>>  .../devicetree/bindings/phy/qcom,qusb2-phy.yaml    | 31 ++++++++++++++++++++--
>>>  arch/arm64/boot/dts/qcom/msm8996.dtsi              | 10 +++++++
>>>  arch/arm64/boot/dts/qcom/sm6125.dtsi               |  3 ++-
>>>  drivers/phy/qualcomm/phy-qcom-qusb2.c              |  4 +--
>>>  4 files changed, 43 insertions(+), 5 deletions(-)
>>> ---
>>
>> Note that msm8996pro may need even more looking into, but that's a
>> story for another day
> 
> JFYI, MSM8996 Pro is being used in the DRM / Mesa CI. If there is an
> important difference, it would be nice to get it sorted out too.

reg   96   pro
0x80 0xF8  0xD0 [!] QUSB2PHY_PORT_TUNE1
0x84 0xB3  0xB3
0x88 0x83  0x83
0x8C 0xC0  0xC0
0x90 none  0x02 [!] QUSB2PHY_PORT_TUNE5
0x08 0x30  0x30
0x0C 0x79  0x79
0x10 0x21  0x21
0x9C 0x14  0x14
0x1C 0x9F  0x9F
0x18 0x00  0x00

apparently this is indeed SoC-specific (via docs) but also apparently
may not be very important (although should be fixed regardless as
some designs may rely on this)

Konrad

Re: [PATCH 0/4] Fix up QUSB2 PHY description for MSM8996/SM61[12]5

[Dmitry Baryshkov]

On Wed, Jun 10, 2026 at 03:13:01PM +0200, Konrad Dybcio wrote:
> On 6/10/26 3:03 PM, Dmitry Baryshkov wrote:
> > On Wed, Jun 10, 2026 at 02:49:31PM +0200, Konrad Dybcio wrote:
> >> On 6/10/26 2:04 PM, Konrad Dybcio wrote:
> >>> The MSM8996 QUSB2PHY was not being guaranteed a power source.
> >>> The SM6125's QUSB2PHY was believed to be idential as the 96 one. It
> >>> wasn't. This series tackles that, freeing us of some dt checker
> >>> errors about vdd-supply not found on MSM8996 boards.
> >>>
> >>> Compile-tested only, but docs confirm my findings..
> >>>
> >>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >>> ---
> >>> Konrad Dybcio (4):
> >>>       dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
> >>>       phy: qcom-qusb2: Fix SM6115 init sequence
> >>>       arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs
> >>>       arm64: dts: qcom: sm6125: Fix QUSB2 compatible
> >>>
> >>>  .../devicetree/bindings/phy/qcom,qusb2-phy.yaml    | 31 ++++++++++++++++++++--
> >>>  arch/arm64/boot/dts/qcom/msm8996.dtsi              | 10 +++++++
> >>>  arch/arm64/boot/dts/qcom/sm6125.dtsi               |  3 ++-
> >>>  drivers/phy/qualcomm/phy-qcom-qusb2.c              |  4 +--
> >>>  4 files changed, 43 insertions(+), 5 deletions(-)
> >>> ---
> >>
> >> Note that msm8996pro may need even more looking into, but that's a
> >> story for another day
> > 
> > JFYI, MSM8996 Pro is being used in the DRM / Mesa CI. If there is an
> > important difference, it would be nice to get it sorted out too.
> 
> reg   96   pro
> 0x80 0xF8  0xD0 [!] QUSB2PHY_PORT_TUNE1
> 0x84 0xB3  0xB3
> 0x88 0x83  0x83
> 0x8C 0xC0  0xC0
> 0x90 none  0x02 [!] QUSB2PHY_PORT_TUNE5
> 0x08 0x30  0x30
> 0x0C 0x79  0x79
> 0x10 0x21  0x21
> 0x9C 0x14  0x14
> 0x1C 0x9F  0x9F
> 0x18 0x00  0x00
> 
> apparently this is indeed SoC-specific (via docs) but also apparently
> may not be very important (although should be fixed regardless as
> some designs may rely on this)

Would you send a patch, please?

> 
> Konrad
> 
> -- 
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy

-- 
With best wishes
Dmitry