From: sashiko-bot@kernel.org
To: "Konrad Dybcio" <konradybcio@kernel.org>
Cc: devicetree@vger.kernel.org, vkoul@kernel.org, robh@kernel.org,
neil.armstrong@linaro.org, linux-phy@lists.infradead.org,
conor+dt@kernel.org, olteanv@gmail.com
Subject: Re: [PATCH v2 1/5] dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
Date: Thu, 03 Sep 2026 14:46:55 +0000 [thread overview]
Message-ID: <20260903144655.BB1791F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260903-topic-8996_61x5_qusb2phy-v2-1-4c3f980a4560@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The binding change causes dtbs_check to fail for existing in-tree MSM8996 and SM6125 device trees, and introduces an architectural disconnect with the driver's unconditional regulator requests.
--
commit a8357f1a883ddad429bf80e6c26f5fba143404de
Author: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
SM6125 DT currently uses just the MSM8996 compatible (without a primary
SM6125-specific one). This commit adds a new compatible for SM6125 with
a SM6115 fallback. It also updates the MSM8996 binding to require
power-domains and required-opps instead of vdd-supply.
> diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
> index 001fd0ccc9852..cfc5a1d16b7f2 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
[ ... ]
> @@ -187,6 +195,22 @@ allOf:
> qcom,preemphasis-width: false
> qcom,hsdisc-trim-value: false
>
> + # On MSM8996, VDD is supplied via the MX power domain
> + - if:
> + properties:
> + compatible:
> + const: qcom,msm8996-qusb2-phy
> + then:
> + required:
> + - power-domains
> + - required-opps
[Severity: Medium]
Will this break dtbs_check for existing in-tree MSM8996 and SM6125 device
trees by mandating power-domains for MSM8996 before the in-tree device
trees are updated?
While this dtbs_check breakage is resolved later in the series by commit
"arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs" and commit
"arm64: dts: qcom: sm6125: Fix QUSB2 compatible", does this change create
an architectural disconnect with the driver that remains unresolved?
Looking at drivers/phy/qualcomm/phy-qcom-qusb2.c, it unconditionally
requires the vdd regulator:
drivers/phy/qualcomm/phy-qcom-qusb2.c:qusb2_phy_vreg_names[] = {
"vdd", "vdda-pll", "vdda-phy-dpdm",
};
If a strictly schema-compliant device tree omits vdd-supply for MSM8996,
would this cause the driver to fail probing when it unconditionally fetches
vdd via devm_regulator_bulk_get()?
> + else:
> + properties:
> + power-domains: false
> + required-opps: false
> + required:
> + - vdd-supply
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-topic-8996_61x5_qusb2phy-v2-0-4c3f980a4560@oss.qualcomm.com?part=1
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Konrad Dybcio" <konradybcio@kernel.org>
Cc: devicetree@vger.kernel.org, vkoul@kernel.org, robh@kernel.org,
neil.armstrong@linaro.org, linux-phy@lists.infradead.org,
conor+dt@kernel.org, olteanv@gmail.com
Subject: Re: [PATCH v2 1/5] dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
Date: Thu, 03 Sep 2026 14:46:55 +0000 [thread overview]
Message-ID: <20260903144655.BB1791F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260903-topic-8996_61x5_qusb2phy-v2-1-4c3f980a4560@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The binding change causes dtbs_check to fail for existing in-tree MSM8996 and SM6125 device trees, and introduces an architectural disconnect with the driver's unconditional regulator requests.
--
commit a8357f1a883ddad429bf80e6c26f5fba143404de
Author: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996
SM6125 DT currently uses just the MSM8996 compatible (without a primary
SM6125-specific one). This commit adds a new compatible for SM6125 with
a SM6115 fallback. It also updates the MSM8996 binding to require
power-domains and required-opps instead of vdd-supply.
> diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
> index 001fd0ccc9852..cfc5a1d16b7f2 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
[ ... ]
> @@ -187,6 +195,22 @@ allOf:
> qcom,preemphasis-width: false
> qcom,hsdisc-trim-value: false
>
> + # On MSM8996, VDD is supplied via the MX power domain
> + - if:
> + properties:
> + compatible:
> + const: qcom,msm8996-qusb2-phy
> + then:
> + required:
> + - power-domains
> + - required-opps
[Severity: Medium]
Will this break dtbs_check for existing in-tree MSM8996 and SM6125 device
trees by mandating power-domains for MSM8996 before the in-tree device
trees are updated?
While this dtbs_check breakage is resolved later in the series by commit
"arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs" and commit
"arm64: dts: qcom: sm6125: Fix QUSB2 compatible", does this change create
an architectural disconnect with the driver that remains unresolved?
Looking at drivers/phy/qualcomm/phy-qcom-qusb2.c, it unconditionally
requires the vdd regulator:
drivers/phy/qualcomm/phy-qcom-qusb2.c:qusb2_phy_vreg_names[] = {
"vdd", "vdda-pll", "vdda-phy-dpdm",
};
If a strictly schema-compliant device tree omits vdd-supply for MSM8996,
would this cause the driver to fail probing when it unconditionally fetches
vdd via devm_regulator_bulk_get()?
> + else:
> + properties:
> + power-domains: false
> + required-opps: false
> + required:
> + - vdd-supply
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-topic-8996_61x5_qusb2phy-v2-0-4c3f980a4560@oss.qualcomm.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-09-03 14:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 14:25 [PATCH v2 0/5] Fix up QUSB2 PHY description for MSM8996/SM61[12]5 Konrad Dybcio
2026-09-03 14:25 ` Konrad Dybcio
2026-09-03 14:25 ` [PATCH v2 1/5] dt-bindings: phy: qcom,qusb2: Straighten out SM6125 and MSM8996 Konrad Dybcio
2026-09-03 14:25 ` Konrad Dybcio
2026-09-03 14:46 ` sashiko-bot [this message]
2026-09-03 14:46 ` sashiko-bot
2026-09-03 14:25 ` [PATCH v2 2/5] phy: qcom-qusb2: Fix SM6115 init sequence Konrad Dybcio
2026-09-03 14:25 ` Konrad Dybcio
2026-09-03 14:25 ` [PATCH v2 3/5] phy: qcom-qusb2: Remove _SHIFT defines Konrad Dybcio
2026-09-03 14:25 ` Konrad Dybcio
2026-09-03 15:03 ` Abel Vesa
2026-09-03 15:03 ` Abel Vesa
2026-09-03 14:25 ` [PATCH v2 4/5] arm64: dts: qcom: msm8996: Add VDD_MX to QUSB2 PHYs Konrad Dybcio
2026-09-03 14:25 ` Konrad Dybcio
2026-09-03 15:02 ` Abel Vesa
2026-09-03 15:02 ` Abel Vesa
2026-09-03 14:25 ` [PATCH v2 5/5] arm64: dts: qcom: sm6125: Fix QUSB2 compatible Konrad Dybcio
2026-09-03 14:25 ` Konrad Dybcio
2026-09-03 15:01 ` Abel Vesa
2026-09-03 15:01 ` Abel Vesa
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=20260903144655.BB1791F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konradybcio@kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--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.