Re: [PATCH 5/6] arm64: dts: qcom: sm6115: Add Motorola Moto G9 Play (guamp)

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 6 potential
issues to consider:
- [High] arm64: dts: qcom: unresolved vreg_l9a phandle breaks guamp DTB
  build
- [High] arm64: dts: qcom: driverless pmi632_lcdb supplies cause panel
  probe deferral
- [High] arm64: dts: qcom: inverted GPIO_ACTIVE_LOW on panel
  enable-gpios
- [Low] arm64: dts: qcom: disallowed input-enable in pm8008_int_default
  TLMM state
- [Low] arm64: dts: qcom: framebuffer@5c000000 unit address without reg
  triggers warning
- [Low] arm64: dts: qcom: sm6115-motorola-guamp-holitech.dtb out of
  alphabetical order
--

commit 08d84af13406d856c30eb5d4421fb4af1a196c93
Author: Val Packett <val@packett.cool>

arm64: dts: qcom: sm6115: Add Motorola Moto G9 Play (guamp)

This commit adds device tree files for the Motorola Moto G9 Play (guamp)
with the Holitech HX83102 display panel and enables building its DTB in
the Qualcomm arm64 Makefile.

> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 88230c4e00ea9..8792a9a0e9e00 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -387,6 +387,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sm4250-oneplus-billie2.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm4450-qrd.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm6115-fxtec-pro1x.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm6115-xiaomi-lemon.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= sm6115-motorola-guamp-holitech.dtb

[Severity: Low]
This isn't a bug, but sm6115-motorola-guamp-holitech.dtb should be placed
before sm6115-xiaomi-lemon.dtb to keep the list in alphabetical order.

> diff --git a/arch/arm64/boot/dts/qcom/sm6115-motorola-guamp-holitech.dts b/arch/arm64/boot/dts/qcom/sm6115-motorola-guamp-holitech.dts
> new file mode 100644
> index 0000000000000..f8e1f9de7e998
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sm6115-motorola-guamp-holitech.dts
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (c) 2026, Val Packett <val@packett.cool>
> + */
> +
> +/dts-v1/;
> +
> +#include "sm6115-motorola-guamp.dtsi"
> +
> +/ {
> +	model = "Motorola Moto G9 Play (Holitech)";
> +	compatible = "motorola,guamp-holitech", "motorola,guamp", "qcom,sm6115";
> +};
> +
> +&panel {
> +	compatible = "holitech,htf065h045", "himax,hx83102";
> +
> +	enable-gpios = <&tlmm 82 GPIO_ACTIVE_LOW>;

[Severity: High]
Is GPIO_ACTIVE_LOW inverted for enable-gpios here?

In drivers/gpu/drm/panel/panel-himax-hx83102.c, hx83102_prepare() sets
enable_gpio to logical 1 to release reset before running ctx->desc->init()
and hx83102_unprepare() sets it to logical 0 before disabling regulators.
With GPIO_ACTIVE_LOW, gpiolib inverts those levels, so gpio82 is driven
physically low while DSI initialization commands are sent and while the
panel is active, and driven physically high when powered off (which also
conflicts with bias-pull-down on gpio82 in mdss_dsi_sleep).

> +	pp1800-supply = <&pm6125_l9a>;

[Severity: High]
Does building sm6115-motorola-guamp-holitech.dtb fail in dtc due to an
unresolved vreg_l9a phandle?

In arch/arm64/boot/dts/qcom/sm6115-motorola-common.dtsi,
/chosen/framebuffer@5c000000 sets vddio-supply = <&vreg_l9a>, whereas the
PM6125 L9 regulator node is labeled pm6125_l9a as used here.

> +
> +	status = "okay";
> +};
> +
> +&pmi632_lcdb {
> +	status = "okay";
> +};

[Severity: High]
Will enabling pmi632_lcdb cause the panel driver to defer probe
indefinitely?

In arch/arm64/boot/dts/qcom/sm6115-motorola-common.dtsi, &panel sets
avdd-supply = <&pmi632_lcdb_ldo> and avee-supply = <&pmi632_lcdb_ncp>.
However, pmi632_lcdb (compatible = "qcom,pmi632-lcdb",
"qcom,pm8150l-lcdb") has no driver or devicetree binding in the tree, so
no regulator_dev is registered for those child nodes.  When
hx83102_panel_add() calls devm_regulator_get() for "avdd" and "avee",
of_regulator_dev_lookup() returns -EPROBE_DEFER and the display panel
never probes (and dtbs_check fails on regulator@ec00).

[ ... ]

> diff --git a/arch/arm64/boot/dts/qcom/sm6115-motorola-guamp.dtsi b/arch/arm64/boot/dts/qcom/sm6115-motorola-guamp.dtsi
> new file mode 100644
> index 0000000000000..7eba684867fb1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sm6115-motorola-guamp.dtsi
> @@ -0,0 +1,127 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (c) 2026, Val Packett <val@packett.cool>
> + */
> +
> +#include "sm6115.dtsi"
> +#include "sm6115-motorola-common.dtsi"

[Severity: Low]
Does /chosen/framebuffer@5c000000 in sm6115-motorola-common.dtsi trigger a
dtc unit_address_vs_reg warning when building this DTB?  That node has a
@5c000000 unit address, but uses memory-region = <&cont_splash_memory>
without a reg or ranges property.

[ ... ]

> +&tlmm {
> +	pm8008_int_default: pm8008-int-default-state {
> +		pins = "gpio25";
> +		function = "gpio";
> +		drive-strength = <2>;
> +		bias-disable;
> +		input-enable;
> +	};

[Severity: Low]
Does input-enable here cause dtbs_check to fail?
Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml sets
input-enable: false for Qualcomm TLMM pin states, and pinctrl-msm ignores
PIN_CONFIG_INPUT_ENABLE.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109221453.658316-1-val@packett.cool?part=5