All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Abel Vesa" <abel.vesa@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH 09/11] arm64: dts: qcom: kodiak: Disable Inline Crypto Engine by default
Date: Fri, 28 Aug 2026 12:56:32 +0000	[thread overview]
Message-ID: <20260828125632.B0C921F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260828-b4-dts-qcom-disable-ice-by-default-v1-9-1d6e0c2f5a69@oss.qualcomm.com>

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

Pre-existing issues:
- [High] UFS host controller probe fails completely if the attached ICE device is marked as disabled in the device tree.
--

commit d5ed75549915409ece5532bca3c5d000fa3bc031
Author: Abel Vesa <abel.vesa@oss.qualcomm.com>

arm64: dts: qcom: kodiak: Disable Inline Crypto Engine by default
    
Disable the Inline Crypto Engine by default in the SoC DTSI and enable
it only in board DTS files that use it. This prevents the UFS_PHY_GDSC
from remaining enabled while the device is idle on boards with no consumers.

> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index f2da3706d5c88..ffbf037b38386 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -2586,6 +2586,8 @@ ice: crypto@1d88000 {
>  			clock-names = "core",
>  				      "iface";
>  			power-domains = <&gcc GCC_UFS_PHY_GDSC>;
> +
> +			status = "disabled";

[Severity: High]
This is a pre-existing issue, but does disabling the ICE node by default cause
the UFS probe to fail completely for any board that leaves it disabled?

When a board's device tree disables the ICE node without deleting the qcom,ice
property from the UFS node, the ICE node is not populated as a platform
device. This causes of_find_device_by_node() to return NULL:

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);
	}
...
}

This error is then returned to the UFS probe:

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);

		dev_warn(dev, "Disabling inline encryption support\n");
		return 0;
	}
...
}

Because ufs_qcom_ice_init() treats -ENODEV as a fatal error rather than
gracefully falling back to disabled hardware encryption, the entire UFS driver
probe aborts and storage fails to initialize.

>  		};
>  
>  		cryptobam: dma-controller@1dc4000 {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828-b4-dts-qcom-disable-ice-by-default-v1-0-1d6e0c2f5a69@oss.qualcomm.com?part=9

  reply	other threads:[~2026-08-28 12:56 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
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 [this message]
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=20260828125632.B0C921F000E9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.