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.
signature.asc
Description: Digital signature
