From: sashiko-bot@kernel.org
To: "Gopikishan Thawre" <gopikishan.thawre@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 3/3] arm64: dts: qcom: lemans: Add Draco EVK board
Date: Tue, 20 Oct 2026 10:28:25 +0000 [thread overview]
Message-ID: <sashiko-outbox-178838@kernel.org> (raw)
In-Reply-To: <20261019-lemans-draco-final-changes-bringup-v1-3-dcabe94f1074@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] arm64: dts: qcom: wrong deprecated phy-supply on serdes0 and serdes1
- [High] arm64: dts: qcom: missing enable-active-high on DP power regulators
- [Low] arm64: dts: qcom: missing unit-address on hsgmii_phy0 and hsgmii_phy1
--
commit 1c47953bff4f7712f8c14ac2bdb120d7a18d16d2
Author: Gopikishan Thawre <gopikishan.thawre@oss.qualcomm.com>
arm64: dts: qcom: lemans: Add Draco EVK board
This commit adds the device tree for the LeMans Draco EVK platform, combining
the LeMans Draco EVK SoM and Draco carrier board with board-specific
peripherals including GPIO expanders, EEPROM, DisplayPort, Ethernet, TPM, and
fan controller.
> diff --git a/arch/arm64/boot/dts/qcom/lemans-draco-evk.dts b/arch/arm64/boot/dts/qcom/lemans-draco-evk.dts
> new file mode 100644
> index 0000000000000..5238157ad0029
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/lemans-draco-evk.dts
> @@ -0,0 +1,543 @@
[ ... ]
> + vreg_dp0_pwr: regulator-dp0-pwr {
> + compatible = "regulator-fixed";
> + regulator-name = "VREG_DP0_PWR_3P3";
> +
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&expander1 7 GPIO_ACTIVE_HIGH>;
> + };
> +
> + vreg_dp1_pwr: regulator-dp1-pwr {
> + compatible = "regulator-fixed";
> + regulator-name = "VREG_DP1_PWR_3P3";
> +
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&expander1 8 GPIO_ACTIVE_HIGH>;
> + };
> +
> + vreg_dp2_pwr: regulator-dp2-pwr {
> + compatible = "regulator-fixed";
> + regulator-name = "VREG_DP2_PWR_3P3";
> +
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&expander1 9 GPIO_ACTIVE_HIGH>;
> + };
> +
> + vreg_dp3_pwr: regulator-dp3-pwr {
> + compatible = "regulator-fixed";
> + regulator-name = "VREG_DP3_PWR_3P3";
> +
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&expander1 10 GPIO_ACTIVE_HIGH>;
> + };
[Severity: High]
Should vreg_dp0_pwr, vreg_dp1_pwr, vreg_dp2_pwr, and vreg_dp3_pwr include the
enable-active-high property?
When reg_fixed_voltage_probe() requests the gpio descriptor for a
regulator-fixed node, the call chain:
of_find_gpio()
-> of_gpio_try_fixup_polarity()
-> of_gpio_set_polarity_by_property()
-> of_gpio_quirk_polarity()
in drivers/gpio/gpiolib-of.c ignores the GPIO_ACTIVE_HIGH phandle flag and
checks only for the presence of enable-active-high:
/*
* The regulator GPIO handles are specified such that the
* presence or absence of "enable-active-high" solely controls
* the polarity of the GPIO line. Any phandle flags must
* be actively ignored.
*/
#if IS_ENABLED(CONFIG_REGULATOR_FIXED_VOLTAGE)
{ "regulator-fixed", "gpios", "enable-active-high" },
{ "regulator-fixed", "gpio", "enable-active-high" },
Without enable-active-high, of_gpio_quirk_polarity() overrides the polarity to
active-low, inverting the enable signal on all four DisplayPort 3.3V power
regulators.
[ ... ]
> +ðernet0 {
> + phy-handle = <&hsgmii_phy0>;
> + phy-mode = "2500base-x";
> +
> + pinctrl-0 = <ðernet0_default>;
> + pinctrl-names = "default";
> +
> + snps,mtl-rx-config = <&mtl_rx_setup>;
> + snps,mtl-tx-config = <&mtl_tx_setup>;
> +
> + nvmem-cells = <&mac_addr0>;
> + nvmem-cell-names = "mac-address";
> +
> + status = "okay";
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hsgmii_phy0: ethernet-phy {
> + compatible = "ethernet-phy-id004d.d101";
> + reg = <0x1c>;
> + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> + };
[ ... ]
> +ðernet1 {
> + phy-handle = <&hsgmii_phy1>;
> + phy-mode = "2500base-x";
> +
> + pinctrl-0 = <ðernet1_default>;
> + pinctrl-names = "default";
> +
> + snps,mtl-rx-config = <&mtl_rx_setup1>;
> + snps,mtl-tx-config = <&mtl_tx_setup1>;
> +
> + nvmem-cells = <&mac_addr1>;
> + nvmem-cell-names = "mac-address";
> +
> + status = "okay";
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hsgmii_phy1: ethernet-phy {
> + compatible = "ethernet-phy-id004d.d101";
> + reg = <0x1c>;
> + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> + };
[Severity: Low]
Should the hsgmii_phy0 and hsgmii_phy1 nodes be named ethernet-phy@1c instead
of ethernet-phy?
Both nodes define reg = <0x1c> under an mdio bus with #address-cells = <1>, so
omitting the unit-address triggers a check_unit_address_vs_reg() warning in
dtc ("node has a reg or ranges property, but no unit name") and fails
dtbs_check against Documentation/devicetree/bindings/net/mdio.yaml.
[ ... ]
> +&serdes0 {
> + phy-supply = <&vreg_l5a>;
> +
> + status = "okay";
> +};
> +
> +&serdes1 {
> + phy-supply = <&vreg_l5a>;
> +
> + status = "okay";
> +};
[Severity: High]
Does configuring serdes0 and serdes1 with phy-supply = <&vreg_l5a> leave the
SGMII PHY without its required 0.9V and 1.2V regulator votes?
In Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml,
phy-supply is deprecated in favor of vdda-0p9-supply and vdda-1p2-supply. In
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c, qcom_dwmac_sgmii_phy_probe() calls
devm_regulator_bulk_get_const() for qcom_dwmac_sgmii_phy_vregs[]:
static const struct regulator_bulk_data qcom_dwmac_sgmii_phy_vregs[] = {
{ .supply = "vdda-0p9", .init_load_uA = 46000 },
{ .supply = "vdda-1p2", .init_load_uA = 15000 },
};
The driver does not request phy-supply, so dummy regulators will be
substituted when qcom_dwmac_sgmii_phy_power_on() enables the bulk supplies
prior to qcom_dwmac_sgmii_phy_calibrate().
As updated for other LeMans boards in commits 4f81684a1d10, 457cf65a7997, and
0d567fb7def9, should serdes0 and serdes1 use:
vdda-0p9-supply = <&vreg_l4a>;
vdda-1p2-supply = <&vreg_l1c>;
instead of phy-supply = <&vreg_l5a>?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261019-lemans-draco-final-changes-bringup-v1-0-dcabe94f1074@oss.qualcomm.com?part=3
prev parent reply other threads:[~2026-10-20 10:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 10:27 [PATCH 0/3] Add support for LeMans Draco EVK board Gopikishan Thawre
2026-10-19 10:27 ` [PATCH 1/3] dt-bindings: arm: qcom: Add " Gopikishan Thawre
2026-10-20 7:51 ` Krzysztof Kozlowski
2026-10-19 10:27 ` [PATCH 2/3] arm64: dts: qcom: lemans: Add Draco EVK SoM platform Gopikishan Thawre
2026-10-20 10:28 ` sashiko-bot
2026-10-19 10:27 ` [PATCH 3/3] arm64: dts: qcom: lemans: Add Draco EVK board Gopikishan Thawre
2026-10-19 12:05 ` Dmitry Baryshkov
2026-10-19 12:31 ` Konrad Dybcio
2026-10-20 10:28 ` sashiko-bot [this message]
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=sashiko-outbox-178838@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gopikishan.thawre@oss.qualcomm.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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