Re: [PATCH v8 2/3] arm64: dts: qcom: kodiak: enable inline crypto engine for SDHC

On 29-06-2026 17:24, Konrad Dybcio wrote:
> On 6/29/26 9:35 AM, Kuldeep Singh wrote:
>> From: Neeraj Soni <[email protected]>
>>
>> Add the dedicated ICE node for kodiak and reference it from the SDHC
>> controller via qcom,ice.
>>
>> Keep the ICE node disabled by default in kodiak.dtsi and enable it in
>> board DTS files where the corresponding SDHC node is enabled.
> 
> Is there a reason to disable it in the first place?
> 
> Keeping it enabled it would ensure that the core is parked
> if it was left on by the bootloader
Yes, observed an issue on kodiak Soc which supports both ufs-ice and
sdhc-ice.

CRYPTO_INLINE_ENGINE flag can be set to m via 2 configs MMC_CRYPTO and
SCSI_UFS_CRYPTO. In default defconfig, SCSI_UFS_CRYPTO is enabled
default and hence, CRYPTO_INLINE_ENGINE is enabled irrespective of
MMC_CRYPTO state.
https://elixir.bootlin.com/linux/v7.1.2/source/arch/arm64/configs/defconfig#L1325
https://elixir.bootlin.com/linux/v7.1.2/source/drivers/mmc/host/Kconfig#L614
https://elixir.bootlin.com/linux/v7.1.2/source/drivers/ufs/host/Kconfig#L62

Kodiak Soc supporting both ufs/sdhc results in initiating both ice
instances which in turn votes the clock in driver. In general, ice clock
suspend/resume sequence is later controller by ufs/sdhc controller once
the corresponding ice instance is initialised.

Since, qcs6490-rb3gen2(having only ufs storage) doesn't have emmc
storage but sdhc-ice DT node still probes the driver, later sdhci-msm
never takes ice instance(as sdhc_1 is disabled) but ice-clocks are
remained voted on.

This results in an issue and hence, trying to fix it by enabling ice
only when corresponding storage controller is enabled be it ufs or sdhc.
ufs/sdhc are default disabled and enabled per DTS, hence following same
convention with ice DT nodes too.

I am planning to update other DTs too with same change.
Suggestions are welcome!

-- 
Regards
Kuldeep