[PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[Krzysztof Kozlowski]

According to user manual / programming guide there is no separate PCIe
phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
4-lane blocks.  This is also visible in memory map, where the 0xf00000
is marked as the main block with additional sub blocks for each 4-lane
phys.

Describing the sub phys without the rest is not correct from hardware
description, even if it works.

Link: https://lore.kernel.org/r/20260420-optimistic-unnatural-stingray-80da35@quoll/
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/glymur-crd.dtsi |  5 ---
 arch/arm64/boot/dts/qcom/glymur.dtsi     | 39 +-----------------------
 2 files changed, 1 insertion(+), 43 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
index 2852d257ac8c..647e934f4edc 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
@@ -440,11 +440,6 @@ &pcie3b {
 	pinctrl-names = "default";
 };
 
-&pcie3b_phy {
-	vdda-phy-supply = <&vreg_l3c_e1_0p89>;
-	vdda-pll-supply = <&vreg_l2c_e1_1p14>;
-};
-
 &pcie3b_port0 {
 	reset-gpios = <&tlmm 155 GPIO_ACTIVE_LOW>;
 	wake-gpios = <&tlmm 157 GPIO_ACTIVE_LOW>;
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index f23cf81ddb77..d5408bd3a389 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -737,7 +737,7 @@ gcc: clock-controller@100000 {
 				 <0>,				/* USB 2 Phy PIPEGMUX */
 				 <0>,				/* USB 2 Phy SYS PCIE PIPEGMUX */
 				 <0>,				/* PCIe 3a */
-				 <&pcie3b_phy>,			/* PCIe 3b */
+				 <0>,				/* PCIe 3b */
 				 <&pcie4_phy>,			/* PCIe 4 */
 				 <&pcie5_phy>,			/* PCIe 5 */
 				 <&pcie6_phy>,			/* PCIe 6 */
@@ -3632,49 +3632,12 @@ pcie3b_port0: pcie@0 {
 				reg = <0x0 0x0 0x0 0x0 0x0>;
 				bus-range = <0x01 0xff>;
 
-				phys = <&pcie3b_phy>;
-
 				#address-cells = <3>;
 				#size-cells = <2>;
 				ranges;
 			};
 		};
 
-		pcie3b_phy: phy@f10000 {
-			compatible = "qcom,glymur-qmp-gen5x4-pcie-phy";
-			reg = <0x0 0x00f10000 0x0 0x10000>;
-
-			clocks = <&gcc GCC_PCIE_PHY_3B_AUX_CLK>,
-				 <&gcc GCC_PCIE_3B_CFG_AHB_CLK>,
-				 <&tcsr TCSR_PCIE_3_CLKREF_EN>,
-				 <&gcc GCC_PCIE_3B_PHY_RCHNG_CLK>,
-				 <&gcc GCC_PCIE_3B_PIPE_CLK>,
-				 <&gcc GCC_PCIE_3B_PIPE_DIV2_CLK>;
-			clock-names = "aux",
-				      "cfg_ahb",
-				      "ref",
-				      "rchng",
-				      "pipe",
-				      "pipediv2";
-
-			resets = <&gcc GCC_PCIE_3B_PHY_BCR>,
-				 <&gcc GCC_PCIE_3B_NOCSR_COM_PHY_BCR>;
-			reset-names = "phy",
-				      "phy_nocsr";
-
-			assigned-clocks = <&gcc GCC_PCIE_3B_PHY_RCHNG_CLK>;
-			assigned-clock-rates = <100000000>;
-
-			power-domains = <&gcc GCC_PCIE_3B_PHY_GDSC>;
-
-			#clock-cells = <0>;
-			clock-output-names = "pcie3b_pipe_clk";
-
-			#phy-cells = <0>;
-
-			status = "disabled";
-		};
-
 		tcsr_mutex: hwlock@1f40000 {
 			compatible = "qcom,tcsr-mutex";
 			reg = <0x0 0x01f40000 0x0 0x20000>;
-- 
2.51.0

Re: [PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[Dmitry Baryshkov]

On Mon, Apr 20, 2026 at 03:36:17PM +0200, Krzysztof Kozlowski wrote:
> According to user manual / programming guide there is no separate PCIe
> phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
> 4-lane blocks.  This is also visible in memory map, where the 0xf00000
> is marked as the main block with additional sub blocks for each 4-lane
> phys.
> 
> Describing the sub phys without the rest is not correct from hardware
> description, even if it works.

Is this the case for the other bifurcated PHYs?

> 
> Link: https://lore.kernel.org/r/20260420-optimistic-unnatural-stingray-80da35@quoll/
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/glymur-crd.dtsi |  5 ---
>  arch/arm64/boot/dts/qcom/glymur.dtsi     | 39 +-----------------------
>  2 files changed, 1 insertion(+), 43 deletions(-)
> 

-- 
With best wishes
Dmitry

Re: [PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[Krzysztof Kozlowski]

On 20/04/2026 20:02, Dmitry Baryshkov wrote:
> On Mon, Apr 20, 2026 at 03:36:17PM +0200, Krzysztof Kozlowski wrote:
>> According to user manual / programming guide there is no separate PCIe
>> phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
>> 4-lane blocks.  This is also visible in memory map, where the 0xf00000
>> is marked as the main block with additional sub blocks for each 4-lane
>> phys.
>>
>> Describing the sub phys without the rest is not correct from hardware
>> description, even if it works.
> 
> Is this the case for the other bifurcated PHYs?
> 

There's more? Oh damn...

Best regards,
Krzysztof

Re: [PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[Dmitry Baryshkov]

On Tue, Apr 21, 2026 at 08:41:14AM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2026 20:02, Dmitry Baryshkov wrote:
> > On Mon, Apr 20, 2026 at 03:36:17PM +0200, Krzysztof Kozlowski wrote:
> >> According to user manual / programming guide there is no separate PCIe
> >> phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
> >> 4-lane blocks.  This is also visible in memory map, where the 0xf00000
> >> is marked as the main block with additional sub blocks for each 4-lane
> >> phys.
> >>
> >> Describing the sub phys without the rest is not correct from hardware
> >> description, even if it works.
> > 
> > Is this the case for the other bifurcated PHYs?
> > 
> 
> There's more? Oh damn...

In the previous generations. I think Hamoa had one.

-- 
With best wishes
Dmitry

Re: [PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[Krzysztof Kozlowski]

On 22/04/2026 22:08, Dmitry Baryshkov wrote:
> On Tue, Apr 21, 2026 at 08:41:14AM +0200, Krzysztof Kozlowski wrote:
>> On 20/04/2026 20:02, Dmitry Baryshkov wrote:
>>> On Mon, Apr 20, 2026 at 03:36:17PM +0200, Krzysztof Kozlowski wrote:
>>>> According to user manual / programming guide there is no separate PCIe
>>>> phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
>>>> 4-lane blocks.  This is also visible in memory map, where the 0xf00000
>>>> is marked as the main block with additional sub blocks for each 4-lane
>>>> phys.
>>>>
>>>> Describing the sub phys without the rest is not correct from hardware
>>>> description, even if it works.
>>>
>>> Is this the case for the other bifurcated PHYs?
>>>
>>
>> There's more? Oh damn...
> 
> In the previous generations. I think Hamoa had one.

Ah, I did not check the others and there is little we can do there -
it's released DTS. This cannot be easily changed while keeping DTS
compatible with users, because probably two PHY nodes will be replaced
by one with different compatible.

Therefore I want to change only the platforms freshly added, where any
incompatibility impact will be minimal.

Best regards,
Krzysztof

Re: [PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[Konrad Dybcio]

On 4/23/26 9:16 AM, Krzysztof Kozlowski wrote:
> On 22/04/2026 22:08, Dmitry Baryshkov wrote:
>> On Tue, Apr 21, 2026 at 08:41:14AM +0200, Krzysztof Kozlowski wrote:
>>> On 20/04/2026 20:02, Dmitry Baryshkov wrote:
>>>> On Mon, Apr 20, 2026 at 03:36:17PM +0200, Krzysztof Kozlowski wrote:
>>>>> According to user manual / programming guide there is no separate PCIe
>>>>> phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
>>>>> 4-lane blocks.  This is also visible in memory map, where the 0xf00000
>>>>> is marked as the main block with additional sub blocks for each 4-lane
>>>>> phys.
>>>>>
>>>>> Describing the sub phys without the rest is not correct from hardware
>>>>> description, even if it works.
>>>>
>>>> Is this the case for the other bifurcated PHYs?
>>>>
>>>
>>> There's more? Oh damn...
>>
>> In the previous generations. I think Hamoa had one.

Any PHY with a name ending in -A or -B. That means:

$ rg 'PCIE_.[AB]_' drivers/clk/qcom/ -l
drivers/clk/qcom/gcc-x1e80100.c
drivers/clk/qcom/gcc-glymur.c
drivers/clk/qcom/gcc-sc8280xp.c


And, quite predictably, some PHYs may not only bifurcate, but also
tri- or quadfurcate (on Nord).

> Ah, I did not check the others and there is little we can do there -
> it's released DTS. This cannot be easily changed while keeping DTS
> compatible with users, because probably two PHY nodes will be replaced
> by one with different compatible.

I think no one utilized the non-reference configuration of those PHYs
in practice. Should a device like that come around though, we'll think
about what to do then..

Konrad

Re: [PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[Krzysztof Kozlowski]

On 24/04/2026 13:09, Konrad Dybcio wrote:
> On 4/23/26 9:16 AM, Krzysztof Kozlowski wrote:
>> On 22/04/2026 22:08, Dmitry Baryshkov wrote:
>>> On Tue, Apr 21, 2026 at 08:41:14AM +0200, Krzysztof Kozlowski wrote:
>>>> On 20/04/2026 20:02, Dmitry Baryshkov wrote:
>>>>> On Mon, Apr 20, 2026 at 03:36:17PM +0200, Krzysztof Kozlowski wrote:
>>>>>> According to user manual / programming guide there is no separate PCIe
>>>>>> phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
>>>>>> 4-lane blocks.  This is also visible in memory map, where the 0xf00000
>>>>>> is marked as the main block with additional sub blocks for each 4-lane
>>>>>> phys.
>>>>>>
>>>>>> Describing the sub phys without the rest is not correct from hardware
>>>>>> description, even if it works.
>>>>>
>>>>> Is this the case for the other bifurcated PHYs?
>>>>>
>>>>
>>>> There's more? Oh damn...
>>>
>>> In the previous generations. I think Hamoa had one.
> 
> Any PHY with a name ending in -A or -B. That means:
> 
> $ rg 'PCIE_.[AB]_' drivers/clk/qcom/ -l
> drivers/clk/qcom/gcc-x1e80100.c
> drivers/clk/qcom/gcc-glymur.c
> drivers/clk/qcom/gcc-sc8280xp.c
> 
> 
> And, quite predictably, some PHYs may not only bifurcate, but also
> tri- or quadfurcate (on Nord).
> 
>> Ah, I did not check the others and there is little we can do there -
>> it's released DTS. This cannot be easily changed while keeping DTS
>> compatible with users, because probably two PHY nodes will be replaced
>> by one with different compatible.
> 
> I think no one utilized the non-reference configuration of those PHYs
> in practice. Should a device like that come around though, we'll think
> about what to do then..
> 

What is the resolution of this discussion? I have impression that no one
objected to my patch, so maybe I should resend it?

Best regards,
Krzysztof

Re: [PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[Konrad Dybcio]

On 6/9/26 12:28 PM, Krzysztof Kozlowski wrote:
> On 24/04/2026 13:09, Konrad Dybcio wrote:
>> On 4/23/26 9:16 AM, Krzysztof Kozlowski wrote:
>>> On 22/04/2026 22:08, Dmitry Baryshkov wrote:
>>>> On Tue, Apr 21, 2026 at 08:41:14AM +0200, Krzysztof Kozlowski wrote:
>>>>> On 20/04/2026 20:02, Dmitry Baryshkov wrote:
>>>>>> On Mon, Apr 20, 2026 at 03:36:17PM +0200, Krzysztof Kozlowski wrote:
>>>>>>> According to user manual / programming guide there is no separate PCIe
>>>>>>> phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
>>>>>>> 4-lane blocks.  This is also visible in memory map, where the 0xf00000
>>>>>>> is marked as the main block with additional sub blocks for each 4-lane
>>>>>>> phys.
>>>>>>>
>>>>>>> Describing the sub phys without the rest is not correct from hardware
>>>>>>> description, even if it works.
>>>>>>
>>>>>> Is this the case for the other bifurcated PHYs?
>>>>>>
>>>>>
>>>>> There's more? Oh damn...
>>>>
>>>> In the previous generations. I think Hamoa had one.
>>
>> Any PHY with a name ending in -A or -B. That means:
>>
>> $ rg 'PCIE_.[AB]_' drivers/clk/qcom/ -l
>> drivers/clk/qcom/gcc-x1e80100.c
>> drivers/clk/qcom/gcc-glymur.c
>> drivers/clk/qcom/gcc-sc8280xp.c
>>
>>
>> And, quite predictably, some PHYs may not only bifurcate, but also
>> tri- or quadfurcate (on Nord).
>>
>>> Ah, I did not check the others and there is little we can do there -
>>> it's released DTS. This cannot be easily changed while keeping DTS
>>> compatible with users, because probably two PHY nodes will be replaced
>>> by one with different compatible.
>>
>> I think no one utilized the non-reference configuration of those PHYs
>> in practice. Should a device like that come around though, we'll think
>> about what to do then..
>>
> 
> What is the resolution of this discussion? I have impression that no one
> objected to my patch, so maybe I should resend it?

Qiang is working on a proper solution to this. PCIe3B is nominally used
for a secondary NVMe, so on the occasion that someone has one inserted,
this isn't really a huge loss (the Yoga laptop and the CRD both have
a primary NVMe on PCIe5 IIRC)

Konrad

Re: [PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[Krzysztof Kozlowski]

On 09/06/2026 15:33, Konrad Dybcio wrote:
> On 6/9/26 12:28 PM, Krzysztof Kozlowski wrote:
>> On 24/04/2026 13:09, Konrad Dybcio wrote:
>>> On 4/23/26 9:16 AM, Krzysztof Kozlowski wrote:
>>>> On 22/04/2026 22:08, Dmitry Baryshkov wrote:
>>>>> On Tue, Apr 21, 2026 at 08:41:14AM +0200, Krzysztof Kozlowski wrote:
>>>>>> On 20/04/2026 20:02, Dmitry Baryshkov wrote:
>>>>>>> On Mon, Apr 20, 2026 at 03:36:17PM +0200, Krzysztof Kozlowski wrote:
>>>>>>>> According to user manual / programming guide there is no separate PCIe
>>>>>>>> phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
>>>>>>>> 4-lane blocks.  This is also visible in memory map, where the 0xf00000
>>>>>>>> is marked as the main block with additional sub blocks for each 4-lane
>>>>>>>> phys.
>>>>>>>>
>>>>>>>> Describing the sub phys without the rest is not correct from hardware
>>>>>>>> description, even if it works.
>>>>>>>
>>>>>>> Is this the case for the other bifurcated PHYs?
>>>>>>>
>>>>>>
>>>>>> There's more? Oh damn...
>>>>>
>>>>> In the previous generations. I think Hamoa had one.
>>>
>>> Any PHY with a name ending in -A or -B. That means:
>>>
>>> $ rg 'PCIE_.[AB]_' drivers/clk/qcom/ -l
>>> drivers/clk/qcom/gcc-x1e80100.c
>>> drivers/clk/qcom/gcc-glymur.c
>>> drivers/clk/qcom/gcc-sc8280xp.c
>>>
>>>
>>> And, quite predictably, some PHYs may not only bifurcate, but also
>>> tri- or quadfurcate (on Nord).
>>>
>>>> Ah, I did not check the others and there is little we can do there -
>>>> it's released DTS. This cannot be easily changed while keeping DTS
>>>> compatible with users, because probably two PHY nodes will be replaced
>>>> by one with different compatible.
>>>
>>> I think no one utilized the non-reference configuration of those PHYs
>>> in practice. Should a device like that come around though, we'll think
>>> about what to do then..
>>>
>>
>> What is the resolution of this discussion? I have impression that no one
>> objected to my patch, so maybe I should resend it?
> 
> Qiang is working on a proper solution to this. PCIe3B is nominally used
> for a secondary NVMe, so on the occasion that someone has one inserted,
> this isn't really a huge loss (the Yoga laptop and the CRD both have
> a primary NVMe on PCIe5 IIRC)

This still should be removed now from the DTS, before you get more users
of it and any change will have impact...

Best regards,
Krzysztof

Re: [PATCH] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B

[Konrad Dybcio]

On 6/9/26 3:41 PM, Krzysztof Kozlowski wrote:
> On 09/06/2026 15:33, Konrad Dybcio wrote:
>> On 6/9/26 12:28 PM, Krzysztof Kozlowski wrote:
>>> On 24/04/2026 13:09, Konrad Dybcio wrote:
>>>> On 4/23/26 9:16 AM, Krzysztof Kozlowski wrote:
>>>>> On 22/04/2026 22:08, Dmitry Baryshkov wrote:
>>>>>> On Tue, Apr 21, 2026 at 08:41:14AM +0200, Krzysztof Kozlowski wrote:
>>>>>>> On 20/04/2026 20:02, Dmitry Baryshkov wrote:
>>>>>>>> On Mon, Apr 20, 2026 at 03:36:17PM +0200, Krzysztof Kozlowski wrote:
>>>>>>>>> According to user manual / programming guide there is no separate PCIe
>>>>>>>>> phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
>>>>>>>>> 4-lane blocks.  This is also visible in memory map, where the 0xf00000
>>>>>>>>> is marked as the main block with additional sub blocks for each 4-lane
>>>>>>>>> phys.
>>>>>>>>>
>>>>>>>>> Describing the sub phys without the rest is not correct from hardware
>>>>>>>>> description, even if it works.
>>>>>>>>
>>>>>>>> Is this the case for the other bifurcated PHYs?
>>>>>>>>
>>>>>>>
>>>>>>> There's more? Oh damn...
>>>>>>
>>>>>> In the previous generations. I think Hamoa had one.
>>>>
>>>> Any PHY with a name ending in -A or -B. That means:
>>>>
>>>> $ rg 'PCIE_.[AB]_' drivers/clk/qcom/ -l
>>>> drivers/clk/qcom/gcc-x1e80100.c
>>>> drivers/clk/qcom/gcc-glymur.c
>>>> drivers/clk/qcom/gcc-sc8280xp.c
>>>>
>>>>
>>>> And, quite predictably, some PHYs may not only bifurcate, but also
>>>> tri- or quadfurcate (on Nord).
>>>>
>>>>> Ah, I did not check the others and there is little we can do there -
>>>>> it's released DTS. This cannot be easily changed while keeping DTS
>>>>> compatible with users, because probably two PHY nodes will be replaced
>>>>> by one with different compatible.
>>>>
>>>> I think no one utilized the non-reference configuration of those PHYs
>>>> in practice. Should a device like that come around though, we'll think
>>>> about what to do then..
>>>>
>>>
>>> What is the resolution of this discussion? I have impression that no one
>>> objected to my patch, so maybe I should resend it?
>>
>> Qiang is working on a proper solution to this. PCIe3B is nominally used
>> for a secondary NVMe, so on the occasion that someone has one inserted,
>> this isn't really a huge loss (the Yoga laptop and the CRD both have
>> a primary NVMe on PCIe5 IIRC)
> 
> This still should be removed now from the DTS, before you get more users
> of it and any change will have impact...

That's what I meant, in a convoluted way, yeah

Konrad