From: sashiko-bot@kernel.org
To: "Abel Vesa" <abel.vesa@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 01/11] arm64: dts: qcom: sm8550: Disable Inline Crypto Engine by default
Date: Fri, 28 Aug 2026 12:47:12 +0000 [thread overview]
Message-ID: <20260828124712.98BE81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260828-b4-dts-qcom-disable-ice-by-default-v1-1-1d6e0c2f5a69@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Disabling the Inline Crypto Engine (ICE) node by default in the SoC DTSI causes UFS probe to fail for any board that enables UFS without explicitly enabling ICE, breaking backward compatibility.
--
commit 16a0192ad11b331cfd04d9e22cced4ae705ad4f3
Author: Abel Vesa <abel.vesa@oss.qualcomm.com>
arm64: dts: qcom: sm8550: Disable Inline Crypto Engine by default
Since UFS_PHY_GDSC is attached to the Inline Crypto Engine and the driver
does not currently enable runtime PM, the GDSC remains enabled while the
device is idle, even on boards where there are no consumers.
So disable the Inline Crypto Engine by default in the SoC DTSI and enable
it only in board DTS files that use it.
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index 0e701e709235c..a2bfd857f3fc0 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -2840,6 +2840,8 @@ ice: crypto@1d88000 {
> clock-names = "core",
> "iface";
> power-domains = <&gcc UFS_PHY_GDSC>;
> +
> + status = "disabled";
[Severity: High]
Does disabling the ICE node by default break backward compatibility for
boards that enable UFS without explicitly enabling ICE?
Since the qcom,ice phandle is retained in the ufs_mem_hc node, when a
board doesn't explicitly set status = "okay" for the ICE node,
of_find_device_by_node() will return NULL for the disabled node.
This causes of_qcom_ice_get() to return -ENODEV instead of -EOPNOTSUPP:
drivers/soc/qcom/ice.c:of_qcom_ice_get() {
...
pdev = of_find_device_by_node(node);
if (!pdev) {
dev_err(dev, "Cannot find device node %s\n", node->name);
return ERR_PTR(-ENODEV);
}
...
}
Because it returns -ENODEV, the UFS driver treats this as a hard error and
aborts the entire UFS probe, rather than gracefully degrading without inline
encryption:
drivers/ufs/host/ufs-qcom.c:ufs_qcom_ice_init() {
...
ice = devm_of_qcom_ice_get(dev);
if (IS_ERR(ice)) {
if (ice != ERR_PTR(-EOPNOTSUPP))
return PTR_ERR(ice);
...
}
Could this prevent the system from booting if the root filesystem is on UFS?
> };
>
> tcsr_mutex: hwlock@1f40000 {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260828-b4-dts-qcom-disable-ice-by-default-v1-0-1d6e0c2f5a69@oss.qualcomm.com?part=1
next prev parent reply other threads:[~2026-08-28 12:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 12:37 [PATCH 00/11] arm64: dts: qcom: Disable Inline Crypto Engine by default accross all SoCs Abel Vesa
2026-08-28 12:37 ` [PATCH 01/11] arm64: dts: qcom: sm8550: Disable Inline Crypto Engine by default Abel Vesa
2026-08-28 12:47 ` sashiko-bot [this message]
2026-08-28 12:37 ` [PATCH 02/11] arm64: dts: qcom: sm8450: " Abel Vesa
2026-08-28 12:52 ` sashiko-bot
2026-08-28 12:37 ` [PATCH 03/11] arm64: dts: qcom: sm8650: " Abel Vesa
2026-08-28 12:52 ` sashiko-bot
2026-08-28 12:37 ` [PATCH 04/11] arm64: dts: qcom: sm8750: " Abel Vesa
2026-08-28 12:37 ` [PATCH 05/11] arm64: dts: qcom: eliza: " Abel Vesa
2026-08-28 12:37 ` [PATCH 06/11] arm64: dts: qcom: kaanapali: " Abel Vesa
2026-08-28 12:37 ` [PATCH 07/11] arm64: dts: qcom: lemans: " Abel Vesa
2026-08-28 12:37 ` [PATCH 08/11] arm64: dts: qcom: milos: " Abel Vesa
2026-08-28 12:37 ` [PATCH 09/11] arm64: dts: qcom: kodiak: " Abel Vesa
2026-08-28 12:56 ` sashiko-bot
2026-08-28 12:37 ` [PATCH 10/11] arm64: dts: qcom: monaco: " Abel Vesa
2026-08-28 12:37 ` [PATCH 11/11] arm64: dts: qcom: sc7180: " Abel Vesa
2026-08-28 12:47 ` [PATCH 00/11] arm64: dts: qcom: Disable Inline Crypto Engine by default accross all SoCs Kuldeep Singh
2026-08-28 12:58 ` Abel Vesa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260828124712.98BE81F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=abel.vesa@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox