From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Qiang Yu <qiang.yu@oss.qualcomm.com>,
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>,
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Manivannan Sadhasivam <mani@kernel.org>
Subject: Re: [PATCH v7 2/6] phy: qcom: qmp-pcie: Add QMP PCIe Multi-PHY driver
Date: Mon, 27 Jul 2026 15:56:53 +0200 [thread overview]
Message-ID: <3b0166c0-e1e7-4746-bcb9-ef78b9a86c8c@oss.qualcomm.com> (raw)
In-Reply-To: <20260724-glymur_linkmode_0724-v7-2-65c8469c6b65@oss.qualcomm.com>
On 7/24/26 12:01 PM, Qiang Yu wrote:
> Some QMP PCIe PHY hardware blocks support multiple link topologies (e.g.
> x8 or x4+x4) selected via a TCSR register. The existing single-instance
> QMP PCIe PHY driver has no way to model this: it assumes a single cfg per
> DT node and instantiates exactly one PHY.
>
> Add a dedicated driver for this class of PHY. Match data carries a
> per-mode cfg table; qmp_pcie_multiphy_probe() reads the current link
> mode from the TCSR register pointed to by "qcom,link-mode", looks up the
> corresponding cfg array, and instantiates one qmp_pcie per sub-PHY
> required by that link mode, registering the clock and #phy-cells = <1> phy
> providers so consumers can address individual sub-PHYs by index.
>
> The driver inherits the phy setting and link-mode programmed by firmware,
> so only the no_csr reset is used and no phy setting tables are provided.
>
> Add the first match data and compatible, qcom,glymur-qmp-gen5x8-pcie-phy,
> for the Glymur Gen5 PCIe PHY that can bifurcate into two x4 links or
> operate as a single x8 link.
>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
This looks really good, couple of follow-up improvement suggestions
[...]
> +static const char * const glymur_pciephy_a_reg_l[] = {
> + "port_a",
> +};
> +
> +static const char * const glymur_pciephy_b_reg_l[] = {
> + "port_b",
> +};
> +
> +static const char * const glymur_pciephy_reg_l[] = {
> + "port_a", "port_b",
> +};
I think we could construct these names at the call sites, with
essentially something like
for (i = 0; i < qmp->num_ports; i++) {
sprintf(buf, "port_%c\n", 'a' + i);
}
(is that too cheesy?)
[...]
> +err_power_off:
> + while (--i >= 0)
> + pm_runtime_put(qmp->pd_devs[i]);
This probably can stay non-sync
> +
> + return ret;
> +}
> +
> +static void qmp_pcie_pd_power_off(struct qmp_pcie *qmp)
> +{
> + const struct qmp_phy_cfg *cfg = qmp->cfg;
> + int i;
> +
> + for (i = cfg->num_pds - 1; i >= 0; i--)
> + pm_runtime_put(qmp->pd_devs[i]);
This should probably be _sync() as phy init/exit may be called in
quick succession
[...]
> +static int __phy_pipe_clk_register(struct device *dev, struct device_node *np,
> + int idx, struct clk_fixed_rate *fixed)
> +{
> + struct clk_init_data init = { };
> + int ret;
> +
> + ret = of_property_read_string_index(np, "clock-output-names", idx,
> + &init.name);
> + if (ret) {
> + dev_err(dev, "%pOFn: No clock-output-names\n", np);
> + return ret;
> + }
> +
> + init.ops = &clk_fixed_rate_ops;
> +
> + if (!fixed->fixed_rate)
> + fixed->fixed_rate = 125000000;
I think this always happens to be true in this driver
[...]
> + num_pipe_outputs = of_property_count_strings(np, "clock-output-names");
> + if (num_pipe_outputs < 0)
> + num_pipe_outputs = 1;
This can't happen (clock-output-names is required via bindings)
[...]
> +static int qmp_pcie_read_link_mode(struct device *dev, unsigned int *link_mode)
> +{
> + struct regmap *map;
> + unsigned int args[1];
> + int ret;
> +
> + map = syscon_regmap_lookup_by_phandle_args(dev->of_node, "qcom,link-mode",
> + ARRAY_SIZE(args), args);
> + if (IS_ERR(map))
> + return PTR_ERR(map);
> +
> + ret = regmap_read(map, args[0], link_mode);
> + if (ret)
> + return ret;
> +
> + return 0;
ret = xxx()
if (ret)
return ret;
return 0;
can be collapsed to simply return regmap_read()
with or without all that,
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-07-27 13:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 10:01 [PATCH v7 0/6] Add QMP PCIe Multi-PHY support Qiang Yu
2026-07-24 10:01 ` [PATCH v7 1/6] dt-bindings: phy: qcom: Add Glymur QMP PCIe multiple link-mode PHY Qiang Yu
2026-07-24 10:01 ` [PATCH v7 2/6] phy: qcom: qmp-pcie: Add QMP PCIe Multi-PHY driver Qiang Yu
2026-07-24 10:12 ` sashiko-bot
2026-07-27 13:56 ` Konrad Dybcio [this message]
2026-07-30 9:18 ` Qiang Yu
2026-07-24 10:01 ` [PATCH v7 3/6] arm64: dts: qcom: glymur: Add PCIe3 PHY and PCIe3a controller nodes Qiang Yu
2026-07-24 10:15 ` sashiko-bot
2026-07-27 14:03 ` Konrad Dybcio
2026-07-24 10:01 ` [PATCH v7 4/6] arm64: dts: qcom: glymur-crd: Add PHY supplies for pcie3_phy Qiang Yu
2026-07-27 14:47 ` Konrad Dybcio
2026-07-29 6:45 ` Qiang Yu
2026-07-29 8:30 ` Konrad Dybcio
2026-07-29 9:11 ` Qiang Yu
2026-07-29 9:22 ` Konrad Dybcio
2026-07-29 9:50 ` Qiang Yu
2026-07-30 9:25 ` Konrad Dybcio
2026-07-31 11:56 ` Abel Vesa
2026-07-24 10:01 ` [PATCH v7 5/6] arm64: dts: qcom: mahua: Replace pcie3a/pcie3_phy with dedicated pcie3b_phy Qiang Yu
2026-07-27 14:08 ` Konrad Dybcio
2026-07-24 10:01 ` [PATCH v7 6/6] arm64: dts: qcom: mahua-crd: Add PHY supplies for pcie3b_phy Qiang Yu
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=3b0166c0-e1e7-4746-bcb9-ef78b9a86c8c@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=mani@kernel.org \
--cc=manivannan.sadhasivam@oss.qualcomm.com \
--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