Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 15:25:37 +0200	[thread overview]
Message-ID: <f83556e7-dbb1-4926-a2a0-4690cdbad941@oss.qualcomm.com> (raw)
In-Reply-To: <alDvnSiplhEg2yhD@hu-qianyu-lv.qualcomm.com>

On 7/10/26 3:11 PM, Qiang Yu wrote:
> On Fri, Jul 10, 2026 at 10:44:20AM +0200, Konrad Dybcio wrote:
>> 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.

[...]

>>>>>>> +			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?
>>
> On QCB, it advertise x8. On CRD, PCIe3a is hidden.

No no, I meant to ask whether we know what the userspace gets to see on
e.g. an AMD system with a bifurcated slot. I would expect that LnkCap
may report a different value, but not necessarily. I would assume we
should probably mimic whatever that does, unless the spec takes a
stance on what should be done.

Konrad

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

      reply	other threads:[~2026-07-10 13:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19  5:47 [PATCH RFC v4 0/9] phy: qcom: qmp-pcie: Add link-mode based support for Glymur Gen5x8 PHY Qiang Yu
2026-05-19  5:47 ` [PATCH RFC v4 1/9] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add glymur-qmp-gen5x8-pcie-phy compatible Qiang Yu
2026-06-16 14:03   ` Konrad Dybcio
2026-06-29  5:14     ` Qiang Yu
2026-06-29  9:20       ` Konrad Dybcio
2026-05-19  5:47 ` [PATCH RFC v4 2/9] dt-bindings: phy: qcom-qmp: Add PHY selector and Glymur link-mode macros Qiang Yu
2026-06-16 14:07   ` Konrad Dybcio
2026-06-29  5:18     ` Qiang Yu
2026-06-29  9:21       ` Konrad Dybcio
2026-05-19  5:47 ` [PATCH RFC v4 3/9] phy: qcom: qmp-pcie: Add multiple power-domains support Qiang Yu
2026-05-19  5:47 ` [PATCH RFC v4 4/9] phy: qcom: qmp-pcie: Support multiple nocsr resets Qiang Yu
2026-05-19  5:47 ` [PATCH RFC v4 5/9] phy: qcom: qmp-pcie: Refactor pipe clk register and parse_dt helpers Qiang Yu
2026-05-20 16:25   ` Dmitry Baryshkov
2026-05-22 10:57     ` Manivannan Sadhasivam
2026-05-28 13:15       ` Qiang Yu
2026-05-28 13:48       ` Dmitry Baryshkov
2026-05-29  7:02         ` Qiang Yu
2026-06-16 14:05           ` Konrad Dybcio
2026-06-29  5:56             ` Qiang Yu
2026-06-29  9:21               ` Konrad Dybcio
2026-05-19  5:47 ` [PATCH RFC v4 6/9] phy: qcom: qmp-pcie: Add clock and reset lists for secondary PHY selector Qiang Yu
2026-05-19  5:47 ` [PATCH RFC v4 7/9] phy: qcom: qmp-pcie: Add link-mode multi-PHY probe infrastructure Qiang Yu
2026-05-19  5:47 ` [PATCH RFC v4 8/9] phy: qcom: qmp-pcie: Add Glymur Gen5x8 PHY config and match data Qiang Yu
2026-05-19  5:47 ` [PATCH RFC v4 9/9] arm64: dts: qcom: glymur: Wire PCIe3a/3b to shared Gen5x8 PHY Qiang Yu
2026-06-17 11:19   ` Konrad Dybcio
2026-06-29  5:05     ` Qiang Yu
2026-06-29  9:20       ` Konrad Dybcio
2026-07-10  2:19         ` Qiang Yu
2026-07-10  8:44           ` Konrad Dybcio
2026-07-10 13:11             ` Qiang Yu
2026-07-10 13:25               ` Konrad Dybcio [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f83556e7-dbb1-4926-a2a0-4690cdbad941@oss.qualcomm.com \
    --to=konrad.dybcio@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=p.zabel@pengutronix.de \
    --cc=qiang.yu@oss.qualcomm.com \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox