Re: [PATCH v4 7/7] arm64: dts: qcom: agatti: Add OPE node

[sashiko-bot@kernel.org]

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

New issues:
- [High] Mismatch in power domain and OPP configurations leading to missing performance state scaling.
- [Medium] The device tree node for `isp_ope` is missing the `status = "disabled";` property, causing it to probe unconditionally.

Pre-existing issues:
- [High] Unchecked return value of `devm_pm_domain_attach_list` masking `-EPROBE_DEFER`.
--

--- Patch [7]: [PATCH v4 7/7] arm64: dts: qcom: agatti: Add OPE node ---
commit fe76d36b157aaeb53ae7054b89db58abbc4862b7
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>

arm64: dts: qcom: agatti: Add OPE node

This commit adds the Offline Processing Engine (OPE) device tree node for
the Agatti platform (QCM2290). The node describes the register regions,
clocks, interrupts, interconnects, IOMMU mappings, and the OPP table.

> diff --git a/arch/arm64/boot/dts/qcom/agatti.dtsi b/arch/arm64/boot/dts/qcom/agatti.dtsi
> index 8a7337239b1eb..8c1ebf82509f9 100644
> --- a/arch/arm64/boot/dts/qcom/agatti.dtsi
> +++ b/arch/arm64/boot/dts/qcom/agatti.dtsi
> @@ -1931,6 +1931,80 @@ port@1 {
>  			};
>  		};
>  
> +		isp_ope: isp@5c42400 {
> +			compatible = "qcom,qcm2290-camss-ope";

[Severity: Medium]
Should this node include a status = "disabled"; property?

Without it, the device probes unconditionally on all QCM2290 boards, even
those without camera hardware, which might consume interconnect bandwidth,
power domains, and clock resources unnecessarily on boot.

> +
> +			reg = <0x0 0x5c42400 0x0 0x200>,

[ ... ]

> +			power-domains = <&gcc GCC_CAMSS_TOP_GDSC>,
> +					<&rpmpd QCM2290_VDDCX>;
> +			power-domain-names = "camss",
> +					      "cx";
> +
> +			ope_opp_table: opp-table {
> +				compatible = "operating-points-v2";
> +
> +				opp-19200000 {
> +					opp-hz = /bits/ 64 <19200000>;
> +					required-opps = <&rpmpd_opp_min_svs>;

[Severity: High]
Does this correctly map the multiple power domains to the OPP table?

The node specifies two power domains (GCC_CAMSS_TOP_GDSC and QCM2290_VDDCX),
but only provides a single phandle per required-opps rather than an array
matching the multiple domains.

Since the OPP core drops the performance state request when the main
device has no power domain (due to being attached as virtual devices),
could the hardware clock scale up without the required VDDCX voltage and
cause a system hang?

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but adding this device tree node
actively triggers a pre-existing issue in the driver's power initialization:

drivers/media/platform/qcom/camss/camss-ope.c:ope_init_power() {
    ...
    devm_pm_domain_attach_list(dev, NULL, &pmdomains);
    ...
}

Is it safe to ignore the return value of devm_pm_domain_attach_list()?

The function can fail, notably with -EPROBE_DEFER if power domains
aren't ready.

Ignoring the return value masks the error and proceeds with probing,
which will lead to the device not powering up correctly at runtime and
bringing the camera subsystem down.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-camss-isp-ope-v4-0-51207a0319d8@oss.qualcomm.com?part=7