Re: [PATCH v6 4/5] arm64: dts: qcom: sm8750-lenovo-elden: add the Lenovo Legion Y700 Gen4

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: sm8750-lenovo-elden: unvalidated skeleton board DTS
--

commit 3e2b204812c71d90f6fa41a9d3a0c687d7154cd7
Author: Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn>

arm64: dts: qcom: sm8750-lenovo-elden: add the Lenovo Legion Y700 Gen4

This commit adds an initial board devicetree for the SM8750-based Lenovo
Legion Y700 Gen4 tablet with the board compatible, chassis type, board
clocks, and firmware-reserved GPIO ranges.

> diff --git a/arch/arm64/boot/dts/qcom/sm8750-lenovo-elden.dts b/arch/arm64/boot/dts/qcom/sm8750-lenovo-elden.dts
> new file mode 100644
> index 0000000000000..821950715c8e4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sm8750-lenovo-elden.dts
> @@ -0,0 +1,50 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2026, Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn>
> + */
> +
> +/dts-v1/;
> +
> +#include "sm8750.dtsi"
> +
> +/ {
> +	model = "Lenovo Legion Y700 Gen4";
> +	compatible = "lenovo,elden", "qcom,sm8750";
> +	chassis-type = "tablet";
> +
> +	clocks {
> +		xo_board: xo-board {
> +			compatible = "fixed-clock";
> +			clock-frequency = <76800000>;
> +			#clock-cells = <0>;
> +		};
> +
> +		sleep_clk: sleep-clk {
> +			compatible = "fixed-clock";
> +			clock-frequency = <32000>;
> +			#clock-cells = <0>;
> +		};
> +
> +		bi_tcxo_div2: bi-tcxo-div2-clk {
> +			compatible = "fixed-factor-clock";
> +			#clock-cells = <0>;
> +
> +			clocks = <&rpmhcc RPMH_CXO_CLK>;
> +			clock-mult = <1>;
> +			clock-div = <2>;
> +		};
> +
> +		bi_tcxo_ao_div2: bi-tcxo-ao-div2-clk {
> +			compatible = "fixed-factor-clock";
> +			#clock-cells = <0>;
> +
> +			clocks = <&rpmhcc RPMH_CXO_CLK_A>;
> +			clock-mult = <1>;
> +			clock-div = <2>;
> +		};
> +	};
> +};
> +
> +&tlmm {
> +	gpio-reserved-ranges = <39 1>, <74 1>;
> +};

[Severity: Medium]
As reported by Konrad Dybcio on v5 [1], is there a reason to include
arch/arm64/boot/dts/qcom/sm8750-lenovo-elden.dts in this series before the
base board enablement can be validated on hardware?

In this patch, the root node and tlmm node in sm8750-lenovo-elden.dts only
define the board clocks (xo_board, sleep_clk, bi_tcxo_div2, and
bi_tcxo_ao_div2) needed to satisfy phandles in sm8750.dtsi and the reserved
GPIO ranges, without SPMI PMICs, RPMh regulators, console, or storage.

Even with the follow-up commit ("arm64: dts: qcom: sm8750-lenovo-elden:
describe the WL2868C regulators"), the board devicetree only enables
gpi_dma2, qupv3_2, and i2c10 with pmic@2f (willsemi,wl2868c) and a
wl2868c_vsys fixed regulator, while leaving out the SPMI PMIC regulators
that supply the WL2868C LDO inputs (in-d12-supply, in-d34-supply,
in-d5-supply, and in-d7-supply), any regulator consumers, and base board
peripherals.

Since the WL2868C devicetree usage is already covered in the example in
Documentation/devicetree/bindings/regulator/willsemi,wl2868c.yaml, should
sm8750-lenovo-elden.dts be deferred to the separate board enablement series
once it can be validated on hardware?

[1] https://lore.kernel.org/r/dddc808a-6407-4db1-aa72-0ebe5652f97c@oss.qualcomm.com

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261104032648.209747-1-xiaqinghuan@mail.ustc.edu.cn?part=4