Re: [PATCH v3 4/4] arm64: dts: qcom: shikra: Add support for AudioCoreCC and AudioCoreCSR nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `audiocore_csr` reset controller is unconditionally enabled by default in the common DT, exposing unclocked or XPU-protected registers on the IQS variant.
--

--- Patch [4]: [PATCH v3 4/4] arm64: dts: qcom: shikra: Add support for AudioCoreCC and AudioCoreCSR nodes ---
commit b6e6ad0368fe6b888bc449723d713689e91d35e8
Author: Imran Shaik <imran.shaik@oss.qualcomm.com>

arm64: dts: qcom: shikra: Add support for AudioCoreCC and AudioCoreCSR nodes

Add support for Audio Core Clock Controller and Audio Core CSR nodes on the
Qualcomm Shikra SoC. The clock and reset requirements differ based on the
audio subsystem enablement across variants. Notably, the IQS variant does not
use soundwire codes, and therefore requires no clocks or resets.

> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index 4e5bc9e17c8ed..b744534572d63 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
[ ... ]
> +		audiocorecc: clock-controller@a0a0000 {
> +			compatible = "qcom,shikra-audiocorecc";
> +			reg = <0x0 0x0a0a0000 0x0 0x10000>;
> +			clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
> +				 <&sleep_clk>,
> +				 <0>;
> +			#clock-cells = <1>;
> +			status = "reserved"; /* Owned by Modem firmware */
> +		};
> +
> +		audiocore_csr: reset-controller@a0b4000 {
> +			compatible = "qcom,shikra-audiocore-csr";
> +			reg = <0x0 0x0a0b4000 0x0 0x1000>;
> +			#reset-cells = <1>;
> +		};

[Severity: High]
Should this node default to disabled or reserved status in the common dtsi?

The commit message notes that the IQS variant does not need clocks or resets.
Since the status property is omitted here, the node will be unconditionally
enabled by default in the common dtsi.

If HLOS probes this device and registers a regmap with debugfs, could a system
diagnostic tool or a privileged user reading the regmap entries trigger an
abort?

Accessing unclocked or XPU-protected registers via
/sys/kernel/debug/regmap/a0b4000.reset-controller/registers could panic the
system on variants like IQS where the hardware is inaccessible to HLOS.

Would it make sense to disable this node by default in shikra.dtsi and only
set status to okay in the board files that require HLOS access?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-shikra-audiocorecc-v3-0-90b878ae0d4e@oss.qualcomm.com?part=4