From: Krzysztof Kozlowski <krzk@kernel.org>
To: Frieder Schrempf <frieder@fris.de>
Cc: Srinivas Kandagatla <srini@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Frank Li <Frank.Li@nxp.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
Shawn Guo <shawnguo@kernel.org>,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Frieder Schrempf <frieder.schrempf@kontron.de>
Subject: Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
Date: Wed, 17 Jun 2026 12:49:01 +0200 [thread overview]
Message-ID: <20260617-prodigious-private-inchworm-beae1e@quoll> (raw)
In-Reply-To: <20260616-upstreaming-next-20260609-imx-ocotp-ele-v1-1-cb7f3698c3e6@kontron.de>
On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> Some SoCs like the i.MX9 family allow full access to the fuses only
> through the secure enclave firmware API. Add a property to reference
> the secure enclave node and let the driver use the API.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> index a8076d0e2737..14a6429f4a4c 100644
> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> @@ -53,6 +53,10 @@ properties:
> reg:
> maxItems: 1
>
> + secure-enclave:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: A phandle to the secure enclave node
Two things here:
1. Here you describe what for is that phandle, how it is used by the
hardware. Currently the description repeats the property name and type,
so not much useful.
2. If you access OTP via firmware, then this is completely different
interface than MMIO, thus:
A. reg is not appropriate
B. Device is very different thus it has different compatible and I even
claim should be in different binding. Devices having completely
different SW interface should not be in the same binding, at least
usually.
If any of above is not accurate, then your commit msg should answer why
and give some background.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-06-17 10:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 11:52 [PATCH 0/9] Support ELE API in i.MX OCOTP NVMEM driver Frieder Schrempf
2026-06-16 11:52 ` [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave Frieder Schrempf
2026-06-17 10:49 ` Krzysztof Kozlowski [this message]
2026-06-17 11:36 ` Frieder Schrempf
2026-06-16 11:52 ` [PATCH 2/9] firmware: imx: ele: Fix indentation in ele_base_msg.h Frieder Schrempf
2026-06-16 11:52 ` [PATCH 3/9] firmware: imx: ele: Add API functions for OCOTP fuse access Frieder Schrempf
2026-06-16 15:36 ` Frank Li
2026-06-16 17:59 ` Frieder Schrempf
2026-06-16 20:05 ` Frank Li
2026-06-17 6:54 ` Frieder Schrempf
2026-06-17 19:56 ` Frank Li
2026-06-16 11:52 ` [PATCH 4/9] nvmem: imx-ocotp-ele: Add keepout table for i.MX93 Frieder Schrempf
2026-06-16 11:52 ` [PATCH 5/9] nvmem: imx-ocotp-ele: Remove device-specific reg_read() Frieder Schrempf
2026-06-16 11:52 ` [PATCH 6/9] nvmem: imx-ocotp-ele: Support the ELE API Frieder Schrempf
2026-06-16 11:52 ` [PATCH 7/9] nvmem: imx-ocotp-ele: Remove the FUSE_ELE type Frieder Schrempf
2026-06-16 11:52 ` [PATCH 8/9] nvmem: imx-ocotp-ele: Rename FSB access map Frieder Schrempf
2026-06-16 11:52 ` [PATCH 9/9] arm64: dts: imx93-kontron: Enable ELE firmware driver Frieder Schrempf
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=20260617-prodigious-private-inchworm-beae1e@quoll \
--to=krzk@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=frieder.schrempf@kontron.de \
--cc=frieder@fris.de \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=srini@kernel.org \
/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