All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: pankaj.gupta@oss.nxp.com
Cc: Frank.Li@kernel.org, robh@kernel.org, imx@lists.linux.dev,
	devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v46 6/7] arm64: dts: imx8ulp: add secure enclave node
Date: Wed, 02 Sep 2026 16:29:52 +0000	[thread overview]
Message-ID: <20260902162953.16E251F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260903-imx-se-if-v46-6-aefaab525034@nxp.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Schema violation: the 'secure-enclave' node lacks the mandatory 'memory-region' property, causing dtbs_check failures for boards that do not enable it.
- [Low] Commit message and code mismatch regarding the SRAM address label.
--

commit a07f75a4e7246d0362429146aa833aff2a0e76b4
Author: Pankaj Gupta <pankaj.gupta@nxp.com>

arm64: dts: imx8ulp: add secure enclave node

This commit adds the EdgeLock Enclave (ELE) secure-enclave node to the
i.MX8ULP SoC dtsi. It adds a label to the SRAM node and introduces the
disabled hsm0 node.

> Add the EdgeLock Enclave (ELE) secure-enclave node to the i.MX8ULP SoC
> dtsi, together with a label for sram@2201f000 that the node references.

[Severity: Low]
The commit message mentions adding a label for sram@2201f000, but the diff
actually applies the 'sram0' label to sram@22010000. Is this a typo in the
commit message, or was the wrong SRAM node labeled?

> Keep the node disabled in the SoC dtsi so it does not impose a
> reserved-memory requirement on every board. Boards enable the enclave and
> provide its memory-region by including imx8ulp-firmware.dtsi.
> 
> Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> 
> ---
> arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> index 777b89ed68490..ac8293f81c6b2 100644
> --- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi

[ ... ]

> @@ -154,7 +154,7 @@ sosc: clock-sosc {
>  		#clock-cells = <0>;
>  	};
>  
> -	sram@22010000 {
> +	sram0: sram@22010000 {
>  		compatible = "mmio-sram";
>  		reg = <0x0 0x22010000 0x0 0x10000>;
>  
> @@ -186,6 +186,14 @@ scmi_sensor: protocol@15 {
>  				#thermal-sensor-cells = <1>;
>  			};
>  		};
> +
> +		hsm0: secure-enclave {
> +			compatible = "fsl,imx8ulp-se-ele-hsm";
> +			mbox-names = "tx", "rx";
> +			mboxes = <&s4muap 0 0>, <&s4muap 1 0>;
> +			sram = <&sram0>;
> +			status = "disabled";
> +		};

[Severity: Medium]
Will this lack of a memory-region property cause dtbs_check validation
failures?

The fsl,imx-se.yaml binding unconditionally requires the memory-region
property for this compatible string. Because dt-schema evaluates all nodes,
even disabled ones, this will structurally conflict and cause dtbs_check to
fail for any board that includes this dtsi without also enabling the node and
providing the memory-region.

Is there a way to avoid imposing dtbs_check failures on boards that do not
configure this enclave?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-imx-se-if-v46-0-aefaab525034@nxp.com?part=6

  reply	other threads:[~2026-09-02 16:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 21:46 [PATCH v46 0/7] firmware: imx: driver for NXP secure-enclave pankaj.gupta
2026-09-02 21:46 ` [PATCH v46 1/7] Documentation/firmware: add imx/se to other_interfaces pankaj.gupta
2026-09-02 21:46 ` [PATCH v46 2/7] dt-bindings: arm: fsl: add imx-se-fw binding doc pankaj.gupta
2026-09-02 21:46 ` [PATCH v46 3/7] firmware: imx: add driver for NXP EdgeLock Enclave pankaj.gupta
2026-09-02 16:28   ` sashiko-bot
2026-09-02 21:46 ` [PATCH v46 4/7] firmware: imx: device context dedicated to priv pankaj.gupta
2026-09-02 21:46 ` [PATCH v46 5/7] firmware: imx: adds miscdev pankaj.gupta
2026-09-02 16:35   ` sashiko-bot
2026-09-02 21:05     ` Frank Li
2026-09-03 11:50       ` Pankaj Gupta (OSS)
2026-09-03 19:49   ` Frank Li
2026-09-02 21:46 ` [PATCH v46 6/7] arm64: dts: imx8ulp: add secure enclave node pankaj.gupta
2026-09-02 16:29   ` sashiko-bot [this message]
2026-09-02 21:46 ` [PATCH v46 7/7] arm64: dts: imx8ulp: add reserved memory for EdgeLock Enclave pankaj.gupta

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=20260902162953.16E251F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=pankaj.gupta@oss.nxp.com \
    --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.