Re: [PATCH v2 1/2] arm64: dts: qcom: sm8750: add reboot-mode support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The reboot mode properties define multiple 32-bit values which will be truncated if using the generic reboot-mode framework.
- [Low] Adding a `reboot-mode` child node to the `psci` node violates the PSCI device tree binding schema.
- [Low] The newly added `reboot-mode` node lacks a `compatible` property, preventing platform drivers from probing it.
- [Low] The commit adds device tree nodes for a `psci-reboot-mode` driver that does not exist in the kernel tree.
--

commit 29b2e890de1b3d908134e3a9d75f1f250b9a8f44
Author: Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>

arm64: dts: qcom: sm8750: add reboot-mode support

This commit adds PSCI SYSTEM_RESET2 reboot-modes for sm8750-mtp and
sm8750-qrd. It defines bootloader and edl modes for use by the
psci-reboot-mode driver.

> Add PSCI SYSTEM_RESET2 reboot-modes for sm8750-mtp and sm8750-qrd for
> use by the psci-reboot-mode driver.

[Severity: Low]
Is the psci-reboot-mode driver available in the kernel tree? It does not
appear to exist in the current tree or in this patch series, which leaves
these device tree nodes as unused code.

> diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> index 3837f6785320d..af4b548d39e91 100644
> --- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
[ ... ]
> @@ -1426,3 +1426,10 @@ &usb_hsphy {
>  
>  	status = "okay";
>  };
> +
> +&psci {
> +	reboot-mode {

[Severity: Low]
Does this new child node violate the PSCI device tree binding schema? The
Documentation/devicetree/bindings/arm/psci.yaml schema specifies
additionalProperties: false at the top level and does not define a
reboot-mode child node, which might cause schema validation to fail with an
additional properties error.

[Severity: Low]
How will the system bind a driver to this node without a compatible
property? Without it, the platform bus will not instantiate a device for
the child node, preventing drivers from probing it natively.

> +		mode-bootloader = <0x80010001 0x2>;
> +		mode-edl = <0x80000000 0x1>;

[Severity: Medium]
Are the second 32-bit cells in these properties going to be ignored? If the
driver hooks into the generic reboot-mode framework in
drivers/power/reset/reboot-mode.c, the framework reads properties prefixed
with mode- using of_property_read_u32().

This function reads strictly the first 32-bit value into the magic field,
so the second parameter might be silently truncated and lost.

> +	};
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529-psci_sys_reset-dt-changes-for-pakala-v2-0-1964ebf1924c@oss.qualcomm.com?part=1