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: 12+ 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 ` David Carlier
2026-08-25 22:57 ` [PATCH 2/2] phy: qcom: qmp-pcie: Check clock-output-names count in " David Carlier
2026-08-25 22:57 ` David Carlier
2026-08-26 9:09 ` Konrad Dybcio
2026-08-26 9:09 ` Konrad Dybcio
2026-09-02 13:58 ` Manivannan Sadhasivam
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
2026-08-26 9:09 ` Konrad Dybcio
2026-09-02 13:56 ` Manivannan Sadhasivam
2026-10-03 15:25 ` Vinod Koul
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.