spi: spi-mem: allow specifying a command's extension
authorPratyush Yadav <p.yadav@ti.com>
Tue, 23 Jun 2020 18:30:15 +0000 (00:00 +0530)
committerMark Brown <broonie@kernel.org>
Tue, 14 Jul 2020 16:29:38 +0000 (17:29 +0100)
commitcaf72df48be32c39f74287976ae843501ae06949
treeabdb40c182052d8987baaf5d716bc18c22d1b3c4
parent4c5e2bba30e49b970a0fd07b43e0b7a3b5fd5ea7
spi: spi-mem: allow specifying a command's extension

In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
the "command extension". There can be 3 types of extensions in xSPI:
repeat, invert, and hex. When the extension type is "repeat", the same
opcode is sent twice. When it is "invert", the second byte is the
inverse of the opcode. When it is "hex" an additional opcode byte based
is sent with the command whose value can be anything.

So, make opcode a 16-bit value and add a 'nbytes', similar to how
multiple address widths are handled.

Some places use sizeof(op->cmd.opcode). Replace them with op->cmd.nbytes

The spi-mxic and spi-zynq-qspi drivers directly use op->cmd.opcode as a
buffer. Now that opcode is a 2-byte field, this can result in different
behaviour depending on if the machine is little endian or big endian.
Extract the opcode in a local 1-byte variable and use that as the buffer
instead. Both these drivers would reject multi-byte opcodes in their
supports_op() hook anyway, so we only need to worry about single-byte
opcodes for now.

The above two changes are put in this commit to keep the series
bisectable.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20200623183030.26591-3-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/spi/spi-mem.c
drivers/spi/spi-mtk-nor.c
drivers/spi/spi-mxic.c
drivers/spi/spi-zynq-qspi.c
include/linux/spi/spi-mem.h