On Fri, 7 Dec 2012 12:41:41 +0900, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Thu, Dec 06, 2012 at 02:04:27PM +, Grant Likely wrote:
Alright, applied. I've also merged in your spi-next tree. Let me know if
that causes problems because it needs to be rebased.
No problem
On Thu, 6 Dec 2012 14:37:33 +0900, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Thu, Dec 06, 2012 at 12:00:26AM +, Grant Likely wrote:
Looks good to me. Probably 3.9 material though.
Acked-by: Grant Likely grant.lik...@secretlab.ca
Hrm, I'd be inclined to apply it now
On Thu, Dec 06, 2012 at 02:04:27PM +, Grant Likely wrote:
Alright, applied. I've also merged in your spi-next tree. Let me know if
that causes problems because it needs to be rebased.
No problem - do you just want to take over the SPI tree again or should
I carry on applying things?
On Sun, 2 Dec 2012 12:54:25 +0900, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
In order to avoid constantly allocating and deallocating there is a fixed
buffer which spi_write_then_read() uses for transfers, with an early error
check to ensure that the transfer fits within the
On Thu, Dec 06, 2012 at 12:00:26AM +, Grant Likely wrote:
Looks good to me. Probably 3.9 material though.
Acked-by: Grant Likely grant.lik...@secretlab.ca
Hrm, I'd be inclined to apply it now - it's isolated enough that it can
be reverted if it explodes and we have the -rc cycle to notice
In order to avoid constantly allocating and deallocating there is a fixed
buffer which spi_write_then_read() uses for transfers, with an early error
check to ensure that the transfer fits within the buffer. This limits the
size of transfers to this size, currently max(32, SMP_CACHE_BYTES).
Since
