Re: [PATCH v1 3/3] arm64: dts: qcom: Add Vicharak Axon Mini

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] The `camera-thermal` zone references a non-existent thermal sensor index.
- [High] The `pm8350c_temp_alarm` node polls the wrong PMIC's die temperature.
- [Medium] The `sdhc_1` eMMC node is missing the `bus-width` property, falling back to 1-bit mode.
- [Low] Peripheral regulators bypass power management by omitting consumers, and the Type-C regulator is completely unpowered.
- [Low] Regulator naming typo for the PCIe1 3.3V supply.
--

commit a197cbbff2c551bcef5dc82c20f61017dc75d278
Author: Ajit Singh <blfizzyy@gmail.com>

arm64: dts: qcom: Add Vicharak Axon Mini

Add DTS for the Vicharak Axon Mini board based on the Qualcomm
QCS6490 SoC. This adds debug UART, eMMC, UFS, SDIO WLAN, USB 2.0
host, PCIe, support along with regulators.

> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-vicharak-axon-mini.dts b/arch/arm64/boot/dts/qcom/qcs6490-vicharak-axon-mini.dts
> new file mode 100644
> index 0000000000000..538485e342ed4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-vicharak-axon-mini.dts

[ ... ]

> +	thermal-zones {
> +		camera-thermal {
> +			polling-delay-passive = <0>;
> +
> +			thermal-sensors = <&pmk8350_adc_tm 2>;

The &pmk8350_adc_tm node only defines subnodes for reg = <0>, reg = <1>, and
reg = <3>.

Does this missing sensor index 2 cause the thermal framework to fail to look
up the sensor and bind the camera thermal zone?

[ ... ]

> +	vcc_5v0_typec0: regulator-vcc-5v0-typec0 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_5v0_typec0";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc_5v0>;
> +
> +		gpio = <&tlmm 54 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc5v0_typec0_en>;
> +	};

Since this regulator lacks both regulator-always-on and a consumer node that
would request it, will this regulator ever be enabled?

Additionally, do regulators like vcc_pcie0_dsi_3v3 and vcc_pcie1_3v3 bypass
runtime power management by relying on regulator-always-on instead of being
linked to their consumers?

[ ... ]

> +	vcc_pcie1_3v3: regulator-vcc-pcie1-3v3 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_pcie_3v3";

This isn't a bug, but the regulator-name omits the index '1' compared to its
node name.

[ ... ]

> +&pm8350c_temp_alarm {
> +	io-channels = <&pmk8350_vadc PMK8350_ADC7_DIE_TEMP>;
> +	io-channel-names = "thermal";
> +};

Does reading PMK8350_ADC7_DIE_TEMP cause the pm8350c_temp_alarm to track the
primary PMK8350 PMIC's temperature instead of its own PM8350C PMIC?

[ ... ]

> +&sdhc_1 {
> +	non-removable;
> +	no-sd;
> +	no-sdio;
> +
> +	vmmc-supply = <&vreg_bob_3p296>;
> +	vqmmc-supply = <&vreg_l19b_1p8>;
> +
> +	status = "okay";
> +};

Does this node fall back to a 1-bit bus width without an explicitly defined
bus-width property, degrading eMMC performance?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518110435.16262-1-blfizzyy@gmail.com?part=3