From: sashiko-bot@kernel.org
To: "David Carlier" <devnexen@gmail.com>
Cc: vkoul@kernel.org, olteanv@gmail.com,
linux-phy@lists.infradead.org, neil.armstrong@linaro.org
Subject: Re: [PATCH 1/2] phy: qcom: qmp-pcie: Select MFD_SYSCON for the multi-PHY driver
Date: Tue, 25 Aug 2026 23:11:07 +0000 [thread overview]
Message-ID: <20260825231107.77BC91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260825225729.230493-1-devnexen@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] Unmet direct dependency warning caused by unconditionally selecting MFD_SYSCON in a driver supporting COMPILE_TEST without inheriting its HAS_IOMEM dependency.
Pre-existing issues:
- [High] Incomplete fix: The regular QMP PCIe driver (PHY_QCOM_QMP_PCIE) also unconditionally calls syscon_regmap_lookup_by_phandle_args() but still lacks a select for MFD_SYSCON, leaving it vulnerable to the exact same probe failure.
--
commit ca7057ced5dd6d2650998c03785e590bdadcd6f2
Author: David Carlier <devnexen@gmail.com>
phy: qcom: qmp-pcie: Select MFD_SYSCON for the multi-PHY driver
The driver reads the active link mode through
syscon_regmap_lookup_by_phandle_args(). Without CONFIG_MFD_SYSCON, the stub
returns -ENOTSUPP, causing probe failures. This patch adds the missing
MFD_SYSCON selection to the PHY_QCOM_QMP_PCIE_MULTIPHY driver.
> diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
> index d910a5d1a1ac3..9113e10992457 100644
> --- a/drivers/phy/qualcomm/Kconfig
> +++ b/drivers/phy/qualcomm/Kconfig
> @@ -81,6 +81,7 @@ config PHY_QCOM_QMP_PCIE_MULTIPHY
> tristate "Qualcomm QMP PCIe Multi PHY Driver"
> depends on PCI || COMPILE_TEST
> select GENERIC_PHY
> + select MFD_SYSCON
[Severity: Low]
Does this unconditionally select MFD_SYSCON without inheriting its hardware
dependencies?
When configuring the kernel with COMPILE_TEST enabled on an architecture
lacking HAS_IOMEM (such as s390 without PCI or UML without IOMEM), this can
trigger Kconfig warnings for unmet direct dependencies and potential build
failures.
[Severity: High]
This is a pre-existing issue, but does the regular PHY_QCOM_QMP_PCIE driver
have the exact same probe failure vulnerability?
In drivers/phy/qualcomm/Kconfig, config PHY_QCOM_QMP_PCIE lacks a select for
MFD_SYSCON:
config PHY_QCOM_QMP_PCIE
tristate "Qualcomm QMP PCIe PHY Driver"
depends on PCI || COMPILE_TEST
select GENERIC_PHY
This driver unconditionally calls syscon_regmap_lookup_by_phandle_args() in
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c:qmp_pcie_get_4ln_config():
tcsr = syscon_regmap_lookup_by_phandle_args(qmp->dev->of_node,
"qcom,4ln-config-sel",
ARRAY_SIZE(args), args);
if (IS_ERR(tcsr)) {
ret = PTR_ERR(tcsr);
if (ret == -ENOENT)
return 0;
dev_err(qmp->dev, "failed to lookup syscon: %d\n", ret);
return ret;
}
If MFD_SYSCON is disabled, the stub returns -ENOTSUPP. Since this explicitly
checks for -ENOENT but not -ENOTSUPP, wouldn't the probe fail unconditionally
and leave the PCIe bus non-functional?
> help
> Enable this to support the QMP PCIe PHY transceiver that is used
> [ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260825225729.230493-1-devnexen@gmail.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-08-25 23:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 22:57 [PATCH 1/2] phy: qcom: qmp-pcie: Select MFD_SYSCON for the multi-PHY driver David Carlier
2026-08-25 22:57 ` [PATCH 2/2] phy: qcom: qmp-pcie: Check clock-output-names count in " David Carlier
2026-08-26 9:09 ` Konrad Dybcio
2026-08-25 23:11 ` sashiko-bot [this message]
2026-08-26 9:09 ` [PATCH 1/2] phy: qcom: qmp-pcie: Select MFD_SYSCON for " Konrad Dybcio
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=20260825231107.77BC91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=devnexen@gmail.com \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
--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