> I'm sorry but the above makes no sense to me. Why on earth would you > need to do these checks?
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. So assuming that the framework is executing those prepare calls itself - say inside the spi_async function - how would it detect such a change without any checksumming the message? Think of 10000 interrupts/s each scheduling the identical SPI message If each check takes 5us to verify the structure is identical to the last call, then that alone sums up to 50ms (or 5% CPU) without doing anything "helpfull". 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). It may even delegate it to multiple masters, but may only use it in one spi bus at a time (this second part should be obvious, as it is in the current API in the form of an implicit requirement from the queue structure member, also 2 channels writing to the same memory location does not make sense - but theoretically would for transmits only). Martin -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
