On Wed, Nov 06, 2013 at 01:10:32PM +0100, Martin Sperl wrote:

> How can you check that the code does not do something like this?

> struct spi_message msg;
> struct spi_transfer a,b;
> spi_message_init(&msg);
> spi_message_add_tail(&msg,&a);
> spi_sync(spi,&msg);
> spi_message_add_tail(&msg,&b);
> spi_sync(spi,msg);

> The above is an allowed sequence, that must work - otherwise we would 
> break an existing API.

This would be broken anyway with existing drivers; if we want to support
that we need to take copies of both the messages and the transfers but
really that just looks crazy.

> The explicit one time call spi_prepare_message states that the driver
> delegates ownership over the message object to the SPI bus-master until 
> it takes ownership back with spi_unprepare_message. So it may not free
> or change the structures in any way, but it still may use the message
> (spi_async) and read write in the data bytes (not the location).

No, modifying an in flight transfer is not supported or sensible.
There's a whole bunch of problems there, including synchronisation with
DMA.