Re: [PATCH v51 5/7] firmware: imx: adds miscdev

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

On Wed, Sep 16, 2026 at 03:16:13PM +0200, Arnd Bergmann wrote:
> On Mon, Sep 14, 2026, at 21:40, pankaj.gupta@oss.nxp.com wrote:
> > From: Pankaj Gupta <pankaj.gupta@nxp.com>
> >
> > Adds the driver for communication interface to secure-enclave, that
> > enables exchanging messages with NXP secure enclave HW IP(s)
> > like EdgeLock Enclave, from:
> > - User-Space Applications via character driver.
> >
> > ABI documentation for the NXP secure-enclave driver.
>
> I just saw this in linux-next, where it has caused a build failure
> for a missing include of linux/slab.h. I hadn't see the series
> before (even though it is a v51, which seems crazy), but I am

It is in linux-next about v37, but build bot find many problems, I dropped
it and request to fix it. And sashiko is online recently and also find many
risk. I request to clean up it, and local AI environment have difference
with sashiko, so bump to v51.

I put to linux-next again to make sure that pass all build test.

Other two problems, need more time to check whole review history. reply
you later.

Frank

> curious about it now.
>
> > User-space library using this driver:
> > - i.MX Secure Enclave library:
> >   -- URL: https://github.com/nxp-imx/imx-secure-enclave.git,
> > - i.MX Secure Middle-Ware:
> >   -- URL: https://github.com/nxp-imx/imx-smw.git
>
> I assume this will hit the soc tree eventually, so I want to
> make sure the reviews have covered all the important aspects here,
> and I don't see the answers in the cover letter:
>
> - Who has reviewed the user interface from outside of NXP?
>   Since this is not a vendor-independent API, I think we have
>   to be extra careful and make sure this does not duplicate
>   anything that is already in the standard firmware interfaces.
>
> - Why is there a low-level passthrough to the firmware from
>   userspace? This looks rather irregular, since it is the kernel's
>   job to abstract the platform and provide vendor-independent
>   interfaces. In particular the bit about shared memory and
>   the generic send/receiv ioctl look like they should not
>   be there, as those would allow side-channels from userspace.
>
>       Arnd
>