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

[Krzysztof Kozlowski <krzk@kernel.org>]

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