Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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