Re: [PATCH 5/7] arm64: dts: qcom: Add LeEco Le2

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Touchscreen and USB nodes are missing `pinctrl` properties, `reset-gpios`, and use invalid downstream interrupt flags.
- [High] The eMMC controller (`sdhc_1`) lacks required `non-removable` and `bus-width = <8>` properties.
- [Medium] Missing `no-map` property in the `cont_splash_mem` reserved-memory region.
- [Medium] Unimplemented features claimed in the commit message (Volume Down key and WLED).
- [Low] Attempting to delete a non-existent device tree node breaks the build.
- [Low] The `ramoops` node has a `reg` property but lacks a unit address in its node name.
--

--- Patch [5]: [PATCH 5/7] arm64: dts: qcom: Add LeEco Le2 ---
commit d23816b713fe6e13030690c43966d4d9b18f3739
Author: Adam Skladowski <a39.skl@gmail.com>

arm64: dts: qcom: Add LeEco Le2

This patch adds a devicetree for the LeEco Le2 smartphone based on the MSM8976
SoC. It claims support for peripherals such as I2C, Power/Volume keys,
regulators, WLED, WCNSS, and GPU.

> Supported functionality as of this initial submission:
> * I2C peripherals (Touchscreen,Audio amp, Haptics, Extcon, Led)
> * Power Button, Volume Keys

[Severity: Medium]
The commit message lists Volume Keys, but only the Volume Up key is defined
in the patch. Was the Volume Down key inadvertently omitted?

> * Regulators (PM8950)
> * WLED (PMI8950)

[Severity: Medium]
The commit message lists WLED, but the pmi8950_wled node below lacks
a status = "okay" property to enable it. Does the WLED function work as is?

[ ... ]
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8976-leeco-s2.dts
[ ... ]
> +	reserved-memory {
> +
> +		ramoops {
> +			compatible = "ramoops";
> +			no-map;
> +			reg = <0 0x9ff00000 0 0x100000>;

[Severity: Low]
Does this node need a unit address in its name to match the reg property
(e.g., ramoops@9ff00000)? Without it, the device tree compiler will generate
a build warning.

> +			record-size = <0x10000>;
> +			console-size = <0x60000>;
> +			ftrace-size = <0x10000>;
> +			pmsg-size = <0x20000>;
> +			ecc-size = <16>;
> +		};
> +
> +		/delete-node/ memory@83000000;

[Severity: Low]
Could this /delete-node/ cause a fatal dtc build failure?

The memory@83000000 node does not appear to exist in the included
msm8976.dtsi or PMIC include files.

> +
> +		cont_splash_mem: memory@82000000 {
> +			reg = <0x0 0x82000000 0x0 0x2800000>;
> +		};

[Severity: Medium]
Should the cont_splash_mem node include the no-map property?

Without it, the kernel maps the region as standard cacheable RAM, which can
cause speculative data aborts, caching issues, or visual corruption if the
bootloader leaves the display controller scanning out from this memory.

[ ... ]
> +&blsp1_i2c4 {
> +	status = "okay";
> +
> +	rmi4-i2c-dev@4b {
> +		reg = <0x4b>;
> +		compatible = "syna,rmi4-i2c";
> +		interrupts-extended = <&tlmm 65 0x2008>;

[Severity: High]
Does this use an invalid downstream interrupt flag? 

0x2008 is usually a downstream wakeup flag that the upstream kernel masks,
meaning it won't be recognized as a wakeup source.

Also, are the pinctrl-names, pinctrl-0, and reset-gpios properties missing
here? 

Without pinctrl, the interrupt pin (gpio65) lacks a pull-up, which can cause
an interrupt storm, and without reset-gpios, the controller might not probe
properly. The ts_int_default and ts_reset_active pinctrl states defined below
appear to be unused.

> +		#address-cells = <1>;
> +		#size-cells = <0>;
[ ... ]
> +&blsp2_i2c2 {
> +	status = "okay";
[ ... ]
> +	tiusb320: tusb320@47 {
> +		compatible = "ti,tusb320";
> +		reg = <0x47>;
> +		interrupts-extended = <&tlmm 21 IRQ_TYPE_EDGE_RISING>;
> +	};

[Severity: High]
Is a pinctrl configuration missing for this interrupt pin?

[ ... ]
> +&sdhc_1 {
> +	vmmc-supply = <&pm8950_l8>;
> +	vqmmc-supply = <&pm8950_l5>;
> +
> +	status = "okay";
> +};

[Severity: High]
Should this eMMC controller node include the non-removable and bus-width = <8>
properties?

Because it is not marked as non-removable, the MMC core may treat it as a
hot-pluggable SD card and poll for Card Detect, causing boot delays. Missing
the bus-width property can also degrade storage throughput by restricting it
to 4-bit or 1-bit mode.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-next-patches-v1-0-79a779d76173@gmail.com?part=5