Sending vendor specific commands to spi-nor flash

[Paul Barker]

Hi,

We're looking to add support for sending vendor specific commands to 
Micron Authenta flash devices over the SPI bus. 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.

[1]: 
https://lore.kernel.org/linux-mtd/20211027103352.8879-1-sshivamurthy@micron.com/T/

Regards,

-- 
Paul Barker
Principal Software Engineer
SanCloud Ltd

e: paul.barker at sancloud.com
w: https://sancloud.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA67255DFCCE62ECD.asc
Type: application/pgp-keys
Size: 7526 bytes
Desc: OpenPGP public key
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20220518/cc38a903/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20220518/cc38a903/attachment-0001.sig>