Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave

[Frank Li <Frank.li@oss.nxp.com>]

On Wed, Jun 17, 2026 at 01:36:30PM +0200, Frieder Schrempf wrote:
> On 17.06.26 12:49, Krzysztof Kozlowski wrote:
> > 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.
>
> Ok, agree.
>
> >
> > 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.
>
> Thanks for the feedback!
>
> The driver currently uses the limited MMIO (FSB) interface to access the
> OTPs. The intention is to support the firmware interface alongside the
> MMIO interface so the driver can pick the interface that is available
> (firmware might not be loaded) and fallback to MMIO.

Does ELE and MMIO access the same bank of fuse? If access the same bank,
why not always use MMIO. Any beneafit from ELE firmware?

Frank
>
> Following your argument would mean a driver deciding by itself which
> interface to use at runtime is not something we want to have in general,
> right?
>
> In turn this would mean we need two drivers, or at least two
> compatibles/bindings for something that is effectively the same hardware.
>
> Actually, my first RFC approach [1] was to create a separate driver. But
> in the end it seemed very weird to have two drivers and two DT nodes for
> the same hardware block. Also I have no idea what happens if both
> interfaces are used at the same time.
>
> The other idea from back then was to replace the MMIO (FSB) interface
> with ELE, but this would mean that we rely on the proprietary ELE
> firmware to be available for simple things like reading a MAC address,
> which is not desirable either, I guess.
>
> In which direction should I move on with this?
>
> [1]
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20250416142715.1042363-1-frieder@fris.de/
>