On Fri, 7 Dec 2012 12:41:41 +0900, Mark Brown
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 - do you just want to take
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?
--
To
On Thu, 6 Dec 2012 14:37:33 +0900, Mark Brown
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
>
> Hrm, I'd be inclined to apply it now - it's isolated enough that it can
> be reverted if
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
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 any
problems.
--
To uns
On Sun, 2 Dec 2012 12:54:25 +0900, Mark Brown
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 buffer. This limits the
> size of tran
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 w
6 matches
Mail list logo
