[PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

[PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

[Mark Brown]

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 we can dynamically allocate and in fact already have a fallback
to do so when there is contention for the fixed buffer remove this
restriction and instead dynamically allocate a suitably sized buffer if
the transfer won't fit.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 drivers/spi/spi.c |   24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index c4f7d71..224b7bc 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1646,12 +1646,18 @@ int spi_write_then_read(struct spi_device *spi,
 	struct spi_transfer	x[2];
 	u8			*local_buf;
 
-	/* Use preallocated DMA-safe buffer.  We can't avoid copying here,
-	 * (as a pure convenience thing), but we can keep heap costs
-	 * out of the hot path ...
+	/* Use preallocated DMA-safe buffer if we can.  We can't avoid
+	 * copying here, (as a pure convenience thing), but we can
+	 * keep heap costs out of the hot path unless someone else is
+	 * using the pre-allocated buffer or the transfer is too large.
 	 */
-	if ((n_tx + n_rx) > SPI_BUFSIZ)
-		return -EINVAL;
+	if ((n_tx + n_rx) > SPI_BUFSIZ || !mutex_trylock(&lock)) {
+		local_buf = kmalloc(max(SPI_BUFSIZ, n_tx + n_rx), GFP_KERNEL);
+		if (!local_buf)
+			return -ENOMEM;
+	} else {
+		local_buf = buf;
+	}
 
 	spi_message_init(&message);
 	memset(x, 0, sizeof x);
@@ -1664,14 +1670,6 @@ int spi_write_then_read(struct spi_device *spi,
 		spi_message_add_tail(&x[1], &message);
 	}
 
-	/* ... unless someone else is using the pre-allocated buffer */
-	if (!mutex_trylock(&lock)) {
-		local_buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
-		if (!local_buf)
-			return -ENOMEM;
-	} else
-		local_buf = buf;
-
 	memcpy(local_buf, txbuf, n_tx);
 	x[0].tx_buf = local_buf;
 	x[1].rx_buf = local_buf + n_tx;
-- 
1.7.10.4

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

[Grant Likely]

On Sun,  2 Dec 2012 12:54:25 +0900, Mark Brown <broonie@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 buffer. This limits the
> size of transfers to this size, currently max(32, SMP_CACHE_BYTES).
> 
> Since we can dynamically allocate and in fact already have a fallback
> to do so when there is contention for the fixed buffer remove this
> restriction and instead dynamically allocate a suitably sized buffer if
> the transfer won't fit.
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Looks good to me. Probably 3.9 material though.

Acked-by: Grant Likely <grant.likely@secretlab.ca>

> ---
>  drivers/spi/spi.c |   24 +++++++++++-------------
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index c4f7d71..224b7bc 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1646,12 +1646,18 @@ int spi_write_then_read(struct spi_device *spi,
>  	struct spi_transfer	x[2];
>  	u8			*local_buf;
>  
> -	/* Use preallocated DMA-safe buffer.  We can't avoid copying here,
> -	 * (as a pure convenience thing), but we can keep heap costs
> -	 * out of the hot path ...
> +	/* Use preallocated DMA-safe buffer if we can.  We can't avoid
> +	 * copying here, (as a pure convenience thing), but we can
> +	 * keep heap costs out of the hot path unless someone else is
> +	 * using the pre-allocated buffer or the transfer is too large.
>  	 */
> -	if ((n_tx + n_rx) > SPI_BUFSIZ)
> -		return -EINVAL;
> +	if ((n_tx + n_rx) > SPI_BUFSIZ || !mutex_trylock(&lock)) {
> +		local_buf = kmalloc(max(SPI_BUFSIZ, n_tx + n_rx), GFP_KERNEL);
> +		if (!local_buf)
> +			return -ENOMEM;
> +	} else {
> +		local_buf = buf;
> +	}
>  
>  	spi_message_init(&message);
>  	memset(x, 0, sizeof x);
> @@ -1664,14 +1670,6 @@ int spi_write_then_read(struct spi_device *spi,
>  		spi_message_add_tail(&x[1], &message);
>  	}
>  
> -	/* ... unless someone else is using the pre-allocated buffer */
> -	if (!mutex_trylock(&lock)) {
> -		local_buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
> -		if (!local_buf)
> -			return -ENOMEM;
> -	} else
> -		local_buf = buf;
> -
>  	memcpy(local_buf, txbuf, n_tx);
>  	x[0].tx_buf = local_buf;
>  	x[1].rx_buf = local_buf + n_tx;
> -- 
> 1.7.10.4
> 

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

[Mark Brown]

On Thu, Dec 06, 2012 at 12:00:26AM +0000, Grant Likely wrote:

> Looks good to me. Probably 3.9 material though.

> Acked-by: Grant Likely <grant.likely@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 any
problems.

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

[Grant Likely]

On Thu, 6 Dec 2012 14:37:33 +0900, Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote:
> On Thu, Dec 06, 2012 at 12:00:26AM +0000, Grant Likely wrote:
> 
> > Looks good to me. Probably 3.9 material though.
> 
> > Acked-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> 
> 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.

Alright, applied. I've also merged in your spi-next tree. Let me know if
that causes problems because it needs to be rebased.

g.


-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

[Grant Likely]

On Thu, 6 Dec 2012 14:37:33 +0900, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Dec 06, 2012 at 12:00:26AM +0000, Grant Likely wrote:
> 
> > Looks good to me. Probably 3.9 material though.
> 
> > Acked-by: Grant Likely <grant.likely@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 any
> problems.

Alright, applied. I've also merged in your spi-next tree. Let me know if
that causes problems because it needs to be rebased.

g.


-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

[Mark Brown]

On Thu, Dec 06, 2012 at 02:04:27PM +0000, 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?

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

[Grant Likely]

On Fri, 7 Dec 2012 12:41:41 +0900, Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote:
> On Thu, Dec 06, 2012 at 02:04:27PM +0000, 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?

Yes, please keep doing what you're doing! It's a huge help.

Whenever I sit down to do patch maintenance, I'll pull in your tree
first. As long as your tree doesn't get rebased then that should work
well. I also promise to not rebase my tree without talking to you first
so you can pull in mine before applying more patches on top.

It's a huge help to be reading through the mailing list and be able to
ignore any messages that I've seen you've already replied to or applied.

g.

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

[Grant Likely]

On Fri, 7 Dec 2012 12:41:41 +0900, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Dec 06, 2012 at 02:04:27PM +0000, 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?

Yes, please keep doing what you're doing! It's a huge help.

Whenever I sit down to do patch maintenance, I'll pull in your tree
first. As long as your tree doesn't get rebased then that should work
well. I also promise to not rebase my tree without talking to you first
so you can pull in mine before applying more patches on top.

It's a huge help to be reading through the mailing list and be able to
ignore any messages that I've seen you've already replied to or applied.

g.

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.