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