slave spi seems badly broken on 4.0 (IDFGH-3885)

[pgu-swir]

No offense, but the slave SPI on v4.0 at least seems to be badly broken

• trying to not use cs_pin (-1) ends up in a crash (not an assert) in spicommon_cs_initialize as the -1 is used to index gpio array
• spi_slave_transmit produces random results in rx data or tx data if one rx_buffer or tx_buffer is not set (one left to NULL and data is incorrect 10% of time - doc says that one can be NULL)
• at least in non-DMA mode, when sending data, if tx_buffer is not in DMA memory, incorrect data is sent
• no other mode than SPI mode 0 seems to be supported
• even when patched spi_common_cs_initialize to accept a cs = -1, received data is incorrect unless DMA is used
• last one, but I assume it's normal but documentation is silent about it : when using non-DMA, callbacks are not activated

[Icarus113]

Q1. Yes, thanks for the report. The crash problem will be fixed soon.
Q2. In CPU-controlled mode: if you don't prepare a tx_buffer, your data won't be copied into the hardware buffer; if no rx_buffer, the data in the hardware buffer will not be moved out. In DMA mode: if you don't prepare corresponding data buffer, the DMA will not start. Therefore, we strongly recommend you to prepare those buffers.
Q3. After checking, transactions under CPU-controlled mode work well.
Q4. After checking, all modes are correctly supported.
Q5. A CS signal is required by the Slave to be triggered. If the CS pin is not correctly set, it won't work as we expect.
Q6. After checking, callbacks work well under CPU-controlled mode.

Thank you very much.

[Alvin1Zhang]

Thanks for reporting, feel free to reopen.