Re: Depreciated spi_master.transfer and "prepared spi messages" for an optimized pipelined-SPI-DMA-driver

[Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

On Wed, Nov 06, 2013 at 08:54:10PM +0100, Martin Sperl wrote:
> >> 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 sequence shown is not broken - see that I have been using spi_sync 
> not spi_async! (think also of people using this via SPIDEV, where you do
> not have such control as you would in kernel space)

Oh, if you're using spi_sync() it's fine but then what's the issue?  The
stack isn't going to remember anything about old messages when they're
resubmitted so why would there ever be any problem?  Even if there were
a problem I can't see how having the core manage things is going to be
an issue.

> Also see the scenario like this:
> * kalloc memory for message
> * add xfers to message
> * call spi_sync
> * kfree xfers
> * kfree message
> * kalloc memory for message
> ** here we may have a high likelihood of getting the same pointer again
> * add xfers to message
> * call spi_sync
> * kfree xfers
> * kfree message

> so we would need again a means to detect such changes.
> The pointers are the same, but the data may be different.

Why would anything even notice a problem?  Like I say by the time the
transfer is returned to the user the stack isn't going to remember
anything about it.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]