Re: [PATCH 5/7] arm64: dts: qcom: sm6375: Make MPM device as part of CPU cluster domain

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Severe integer overflow in `mpm_write_next_wakeup` when no hrtimers are pending causes immediate spurious wakeups.

Pre-existing issues:
- [High] The MPM power domain probe dependency and DT validation bug fixed in sm6375.dtsi remains in agatti.dtsi and shikra.dtsi, permanently breaking CPU idle states.
--

--- Patch [5]: [PATCH 5/7] arm64: dts: qcom: sm6375: Make MPM device as part of CPU cluster domain ---
commit b04aa9c0b185843b6783d946292d656585dedf48
Author: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
arm64: dts: qcom: sm6375: Make MPM device as part of CPU cluster domain

This commit removes the power domain provider property from the MPM device
in the sm6375 device tree to prevent idle-state initialization failures.
It then assigns the MPM device to the CPU cluster power domain.

> diff --git a/arch/arm64/boot/dts/qcom/sm6375.dtsi b/arch/arm64/boot/dts/qcom/sm6375.dtsi
> index ccf572bb1549b..5f729634e1d9b 100644
> --- a/arch/arm64/boot/dts/qcom/sm6375.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm6375.dtsi
> @@ -318,7 +318,7 @@ mpm: interrupt-controller {
>  		mboxes = <&ipcc IPCC_CLIENT_AOP IPCC_MPROC_SIGNAL_SMP2P>;
>  		interrupt-controller;
>  		#interrupt-cells = <2>;
> -		#power-domain-cells = <0>;
> +		power-domains = <&cluster_pd>;

[Severity: High]
This is a pre-existing issue, but does the same problem still exist in other
device trees like agatti.dtsi and shikra.dtsi?

Because the qcom_mpm driver no longer registers a power domain, the cluster_pd
node in agatti.dtsi incorrectly relies on &mpm as a power domain provider:

arch/arm64/boot/dts/qcom/agatti.dtsi:cluster_pd {
    ...
	power-domains = <&mpm>;
    ...
}

Will this cause cluster_pd to perpetually fail to probe with -EPROBE_DEFER
and permanently break the CPU power-collapse idle state?

Also, both agatti.dtsi and shikra.dtsi incorrectly retain the deprecated
#power-domain-cells = <0>; property in their MPM nodes:

arch/arm64/boot/dts/qcom/agatti.dtsi:mpm {
    ...
	#power-domain-cells = <0>;
    ...
}

>  		interrupt-parent = <&intc>;
>  		qcom,mpm-pin-count = <96>;
>  		qcom,mpm-pin-map = <5 296>,  /* Soundwire wake_irq */
> @@ -505,7 +505,6 @@ cpu_pd7: power-domain-cpu7 {
>  
>  		cluster_pd: power-domain-cpu-cluster0 {
>  			#power-domain-cells = <0>;
> -			power-domains = <&mpm>;
>  			domain-idle-states = <&cluster_sleep_0>;
>  		};
>  	};

[Severity: High]
Does this change trigger an integer overflow in mpm_write_next_wakeup() when
no hrtimers are pending?

If dev_pm_genpd_get_next_hrtimer() returns KTIME_MAX, it is processed without
bounds checking:

drivers/irqchip/irq-qcom-mpm.c:mpm_write_next_wakeup() {
    ...
	wakeup = dev_pm_genpd_get_next_hrtimer(priv->dev);

	/* Find the relative wakeup in kernel time scale */
	now = ktime_get();
	wakeup = ktime_sub(wakeup, now);
	wakeup_us = ktime_to_us(wakeup);

	/* Convert the wakeup to arch timer scale */
	wakeup_cycles = USECS_TO_CYCLES(wakeup_us);
    ...
}

This evaluates to a massive value which causes xloops_to_cycles() to overflow
the 64-bit integer multiple times over:

drivers/irqchip/irq-qcom-mpm.c:xloops_to_cycles() {
    ...
	return (xloops * loops_per_jiffy * HZ) >> 32;
    ...
}

Could this result in the hardware being programmed with a pseudo-random timer
value, triggering an immediate or severely premature wakeup that destroys deep
sleep power savings?

Should mpm_write_next_wakeup() explicitly check for wakeup == KTIME_MAX to
avoid this overflow?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713-b4-shikra_lpm_addition-v1-0-3d858df2cbbf@oss.qualcomm.com?part=5