SPI API improvements proposals

[anangl]

1. rx_bufs parameter (in spi_transceive and spi_transceive_async functions) could be declared as a pointer to a constant structure, as the content of any RX buffer structure is not (and shouldn't be) modified, only what its buf member points to is a subject to modification. This would allow to pass an array of RX buffers stored in flash as the parameter. Currently this is not possible without artificial typecasting.
2. The same applies to config parameter in all functions exposed by this API. Although this structure can not be placed in flash (because of its dev member that is filled in runtime), it is not supposed to be modified inside SPI drivers, thus it should be marked as such.
3. "EEPROM read mode" should be described (it is not a widely known feature) and I think this feature should be optional, since it may be troublesome to implement for some controllers. What would be wrong when a driver returns an error when it does not provide this option?
4. spi_transceive and spi_transceive_async take too many parameters. This will be ineffective (at least on some architectures) as it will force placing some of them on stack. And some of these parameters are tightly coupled (like tx_bufs and tx_count), so it feels natural to pack them in structures (which will be constant, so they can be placed in flash). Then, if one direction of the transfer is not needed (in spi_read and spi_write) a single NULL instead of a pair NULL, 0 could be passed instead of a structure for this direction.
5. I think it would be clearer if the asynchronous part was enabled not by CONFIG_POLL directly but by some config option with a more SPI related name that depends on POLL. This would also allow building only the synchronous part of the SPI driver in a system with POLL enabled (in case someone finds such fancy setup useful).

[anangl]

@tbursztyka Could you have a look at these?

[tbursztyka]

1. I am fine with the const issue. However, the "stored in flash" argument is unlikely to happen so often: the nature of scatter-gather buffer makes it very flexible so at runtime you can tweak buf/len to full-fill various and different transactions. This makes easy to save ram as you can use only one short array of spi_buf for both rx/tx. Of course that fully depends on the protocol your are implementing, but it would be counter-productive not using this flexibility.
2. sure
3. maybe we can get rid of it
4. sure (same issue with flash storing, if one can use always the same rx/tx spi_buf, it's fine. If not...)
5. what about CONFIG_SPI_ASYNC ?

[tbursztyka]

I am on it.