All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Xing Loong" <xing.xl.loong@gmail.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v3 2/3] dt-bindings: firmware: add mbedtee,tee binding
Date: Mon, 20 Jul 2026 07:48:46 +0000	[thread overview]
Message-ID: <20260720074847.61FB81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720073558.799755-3-xing.xl.loong@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The YAML examples will fail `make dt_binding_check` with `dtc` compilation errors due to unresolved phandle references.
- [Low] Top-level `items` for `memory-region-names` is defined as an object `enum` rather than a list, leading to unnecessary schema complexity and bypassing strict sequence expectations.
--

--- Patch [2]: [PATCH v3 2/3] dt-bindings: firmware: add mbedtee,tee binding ---
commit 2b2356c421476302d4bae45809eeb06223db44ab
Author: Xing Loong <xing.xl.loong@gmail.com>

dt-bindings: firmware: add mbedtee,tee binding
    
This commit adds a new device tree binding for MbedTEE, a Trusted
Execution Environment. It supports communication via shared memory ring
buffers on ARM and RISC-V platforms.

> diff --git a/Documentation/devicetree/bindings/firmware/mbedtee,tee.yaml b/Documentation/devicetree/bindings/firmware/mbedtee,tee.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/mbedtee,tee.yaml

[ ... ]

> +  memory-region-names:
> +    minItems: 2
> +    maxItems: 3
> +    items:
> +      enum:
> +        - t2r-ring
> +        - t2r-shm
> +        - r2t-ring

[Severity: Low]
Does this top-level enum definition bypass the strict sequence expectations
for *-names properties?

Typically, items should be an ordered list of elements. Defining it as an enum
here allows the names to appear in any order, which is later overridden in the
allOf branches. Could this be simplified by defining the exact list of const
elements at the top level?

[ ... ]

> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +    firmware {
> +        mbedtee {
> +            compatible = "mbedtee,tee";
> +            interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>;
> +            memory-region = <&t2r_ring>, <&t2r_shm>;
> +            memory-region-names = "t2r-ring", "t2r-shm";
> +        };
> +    };
> +
> +  - |
> +    firmware {
> +        mbedtee {
> +            compatible = "mbedtee,tee";
> +            msi-parent = <&imsic>;
> +            memory-region = <&t2r_ring>, <&t2r_shm>, <&r2t_ring>;
> +            memory-region-names = "t2r-ring", "t2r-shm", "r2t-ring";
> +        };
> +    };

[Severity: Low]
Will these examples fail make dt_binding_check with dtc compilation errors?

The phandles like <&t2r_ring>, <&t2r_shm>, <&r2t_ring>, and <&imsic> are used
here but are not defined as stub nodes anywhere in the example blocks. The
device tree compiler generally cannot resolve these phandles without the stub
definitions.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720073558.799755-1-xing.xl.loong@gmail.com?part=2

  reply	other threads:[~2026-07-20  7:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20  7:35 [PATCH v3 0/3] tee: add MbedTEE driver Xing Loong
2026-07-20  7:35 ` Xing Loong
2026-07-20  7:35 ` [PATCH v3 1/3] dt-bindings: vendor-prefixes: add mbedtee Xing Loong
2026-07-20  7:35   ` Xing Loong
2026-07-20  7:35 ` [PATCH v3 2/3] dt-bindings: firmware: add mbedtee,tee binding Xing Loong
2026-07-20  7:35   ` Xing Loong
2026-07-20  7:48   ` sashiko-bot [this message]
2026-07-20  7:35 ` [PATCH v3 3/3] tee: add MbedTEE driver Xing Loong
2026-07-20  7:35   ` Xing Loong
2026-07-20  7:55   ` sashiko-bot

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=20260720074847.61FB81F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=xing.xl.loong@gmail.com \
    /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.