Re: [PATCH RFC v4 9/9] arm64: dts: qcom: glymur: Wire PCIe3a/3b to shared Gen5x8 PHY

From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Qiang Yu <qiang.yu@oss.qualcomm.com>
Cc: Vinod Koul <vkoul@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC v4 9/9] arm64: dts: qcom: glymur: Wire PCIe3a/3b to shared Gen5x8 PHY
Date: Fri, 10 Jul 2026 10:44:20 +0200	[thread overview]
Message-ID: <6802dc29-d783-40df-bbb8-8b2dbd94be29@oss.qualcomm.com> (raw)
In-Reply-To: <alBWrK8X7fW+UC7L@hu-qianyu-lv.qualcomm.com>

On 7/10/26 4:19 AM, Qiang Yu wrote:
> On Mon, Jun 29, 2026 at 11:20:07AM +0200, Konrad Dybcio wrote:
>> On 6/29/26 7:05 AM, Qiang Yu wrote:
>>> On Wed, Jun 17, 2026 at 01:19:49PM +0200, Konrad Dybcio wrote:
>>>> On 5/19/26 7:47 AM, Qiang Yu wrote:
>>>>> Glymur PCIe3 uses a single shared Gen5x8 QMP PHY block. Model PCIe3a and
>>>>> PCIe3b as consumers of that shared PHY provider instead of separate PHY
>>>>> nodes.
>>>>>
>>>>> Update the DTS wiring to:
>>>>> - point GCC PCIe3A/3B pipe parents to the shared PHY clock outputs
>>>>> - add PCIe3a controller node and route PCIe3a/PCIe3b port phys to
>>>>>   &pcie3_phy using two-cell PHY arguments
>>>>> - configure the shared PHY node with link-mode and dual pipe outputs
>>>>>
>>>>> Use QMP_PCIE_GLYMUR_MODE_* dt-binding macros for mode selection.
>>>>>
>>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> +		pcie3a: pci@1c10000 {
>>>>> +			device_type = "pci";
>>>>> +			compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
>>>>> +			reg = <0x0 0x01c10000 0x0 0x3000>,
>>>>> +			      <0x0 0x70000000 0x0 0xf20>,
>>>>> +			      <0x0 0x70000f40 0x0 0xa8>,
>>>>> +			      <0x0 0x70001000 0x0 0x4000>,
>>>>> +			      <0x0 0x70100000 0x0 0x100000>,
>>>>> +			      <0x0 0x01c13000 0x0 0x1000>;
>>>>> +			reg-names = "parf",
>>>>> +				    "dbi",
>>>>> +				    "elbi",
>>>>> +				    "atu",
>>>>> +				    "config",
>>>>> +				    "mhi";
>>>>> +			#address-cells = <3>;
>>>>> +			#size-cells = <2>;
>>>>> +			ranges = <0x01000000 0x0 0x00000000 0x0 0x70200000 0x0 0x100000>,
>>>>> +				 <0x02000000 0x0 0x70000000 0x0 0x70300000 0x0 0x3d00000>,
>>>>> +				 <0x03000000 0x7 0x00000000 0x7 0x00000000 0x0 0x40000000>,
>>>>> +				 <0x43000000 0x70 0x00000000 0x70 0x00000000 0x10 0x00000000>;
>>>>> +
>>>>> +			bus-range = <0 0xff>;
>>>>> +
>>>>> +			dma-coherent;
>>>>> +
>>>>> +			linux,pci-domain = <3>;
>>>>> +			num-lanes = <8>;
>>>>
>>>> Is it fine to keep num-lanes 8 here even for configurations with
>>>> bifurcated PHY?
>>>>
>>>> I would assume so, given essentially this is a x8 host, whose 4
>>>> lanes may simply be effectively NC 
>>>>
>>> Actually, on existing platforms, the PCIe3a and PCIe3b controllers are
>>> never enabled at the same time. When PCIe3a is exposed, it is always in an
>>> x8 slot. But if we have a x4+x4 platform in future, we can simply override
>>> num-lanes to 4 in the board.dts.
>>
>> My question is whether that will be necessary - if yes, sure, we
>> can do it, but if not, we can conclude on this early and not have
>> to fight over it in a couple months
>>
> I think we do need to override it in that case. If both PCIe3a and PCIe3b
> are enabled in x4+x4 mode but PCIe3a keeps num-lanes = <8>, userspace
> will see an 8-lane slot. If an x8-capable EP is connected to that slot,
> both ends will advertise x8 support, but the link is up at x4. That looks
> like a genuine bug from the user's point of view.

Do we know what's advertised on x86 PCs with bifurcated lanes?

Konrad

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