SPI driver change breaks multi-transfer messages so spi-nor devices are not working any longer.

Hi,

this commit https://github.com/intel/linux-intel-lts/commit/d54468e3bedff85f4f0f8c09a4c1ca3f3fe858d8 introduces SPI CS handling in the spi controller driver while it should be and is handled in spi_transfer_one_message().
https://github.com/intel/linux-intel-lts/blob/5.15/linux/drivers/spi/spi.c#L1361

This breaks any message consisting of two transfers, e.g. generated by spi-nor via spi-mem.
https://elixir.bootlin.com/linux/v5.10.156/source/drivers/spi/spi-mem.c#L329

spi-nor constructs a message consisting of at least two transfers, one byte for the command SPINOR_OP_RDID and another one for the response id. https://elixir.bootlin.com/linux/v5.10.156/source/drivers/spi/spi-mem.c#L329
Releasing the chipselect after SPINOR_OP_RDID interrupts the transfer, so no chip id is read.

To my knowledge this patch never made it into vanilla kernel as well.

Best regards,
Markus

Read drivers/spi/spi.c around spi_transfer_one_message() and compare the chip-select handling introduced by commit d54468e3bedff85f4f0f8c09a4c1ca3f3fe858d. Then trace the multi-transfer path in drivers/spi/spi-mem.c, where spi-nor builds the SPINOR_OP_RDID message. Done means a multi-transfer spi-nor message keeps chip select asserted and successfully reads the response ID.

Written by the indexing model from the issue text.