Sending vendor specific commands to spi-nor flash

Michael Walle michael at walle.cc
Mon May 23 01:31:13 PDT 2022


Hi,

Am 2022-05-18 14:32, schrieb Paul Barker:
> We're looking to add support for sending vendor specific commands to
> Micron Authenta flash devices over the SPI bus.

Please elaborate a bit more on the use case. Is this something specific
to the flash or is it more of a general feature?

> Since we're using the
> MTD block interface to support a filesystem on the SPI flash we need
> to send these vendor specific commands via some sort of IOCTL.
> 
> I can see a couple of ways to achieve this (as follows) and would like
> to get some feedback from the MTD & spi-nor maintainers on which
> approach is preferred:
> 
> 1) Add new IOCTLs to the mtdchar device to support these vendor
> specific operations. An initial set of patches was sent back in
> October 2021 which took this route [1], but no further progress was
> made. The new IOCTLs would exist for all mtdchar devices (regardless
> of vendor) if we go this route and we'd need to ensure -EINVAL or
> -ENOTSUPP is returned as appropriate if these IOCTLs are called on a
> device which does not implement them.
> 
> 2) Add a vendor-specific IOCTL layer to the mtdchar device interface.
> When the mtdchar IOCTL handler is called with a command not defined in
> mtdchar.c, pass the call on to a device-specific IOCTL handler which
> can potentially handle vendor specific commands.
> 
> 3) Add a generic SPI transfer IOCTL for spi-nor MTD devices. This
> would avoid the need to define IOCTLs for every vendor specific
> command supported by SPI flash devices. Instead, knowledge of the
> vendor specific commands would be kept in userspace and the kernel
> would simply provide an API for sending & receiving arbitrary bytes
> over the SPI bus. This is similar to the MMC_IOC_CMD IOCTL supported
> by the MMC driver.
> 
> My preference would be for option (3) since it minimizes the scope of
> the changes we need to make in the kernel. We're not tied to this
> though, so let us know if a different option is preferred.

I'm not sure we should allow a generic "issue anything to the spi
flash". It it is just a one time thing, like for example, program
a password during production, or program non-volatile memory during
production of the board, I'm fine with it. Most probably, calling
that ioctl will also call add_taint(). This will also need to go
with proper userspace util support.

But if it is something for general use, please provide a proper API
and don't write userspace drivers.

-michael



More information about the linux-mtd mailing list