mtd: devices: m25p80: Make the buffer passed in op is DMA-able

Message ID 20180917133652.12442-1-boris.brezillon@bootlin.com
State New
Delegated to: Boris Brezillon
Headers show
Series
  • mtd: devices: m25p80: Make the buffer passed in op is DMA-able
Related show

Commit Message

Boris Brezillon Sept. 17, 2018, 1:36 p.m.
As documented in spi-mem.h, spi_mem_op->data.buf.{in,out} must be
DMA-able, and commit 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx()
API") failed to follow this rule as buffers passed to
->{read,write}_reg() are usually placed on the stack.

Fix that by allocating a scratch buffer and copying the data in there
before passing it to the spi-mem layer.

Fixes: 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx() API")
Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
---
Note that the ->{read,write}() path is still buggy since nothing
guarantees that buffers passed by the MTD layer to the SPI NOR layer
are DMA-able, but this is a long-standing issue which we'll have to
address at the spi-nor level (this layer can choose the bounce buffer
size based on nor->page_size).
---
 drivers/mtd/devices/m25p80.c | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

Comments

Boris Brezillon Sept. 17, 2018, 1:38 p.m. | #1
Oops. You should read "Make *sure* ...".

On Mon, 17 Sep 2018 15:36:52 +0200
Boris Brezillon <boris.brezillon@bootlin.com> wrote:

> As documented in spi-mem.h, spi_mem_op->data.buf.{in,out} must be
> DMA-able, and commit 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx()
> API") failed to follow this rule as buffers passed to
> ->{read,write}_reg() are usually placed on the stack.  
> 
> Fix that by allocating a scratch buffer and copying the data in there
> before passing it to the spi-mem layer.
> 
> Fixes: 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx() API")
> Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> ---
> Note that the ->{read,write}() path is still buggy since nothing
> guarantees that buffers passed by the MTD layer to the SPI NOR layer
> are DMA-able, but this is a long-standing issue which we'll have to
> address at the spi-nor level (this layer can choose the bounce buffer
> size based on nor->page_size).
> ---
>  drivers/mtd/devices/m25p80.c | 24 +++++++++++++++++++++---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index cbfafc453274..3b7fafa4bbd6 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -39,14 +39,22 @@ static int m25p80_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
>  	struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
>  					  SPI_MEM_OP_NO_ADDR,
>  					  SPI_MEM_OP_NO_DUMMY,
> -					  SPI_MEM_OP_DATA_IN(len, val, 1));
> +					  SPI_MEM_OP_DATA_IN(len, NULL, 1));
> +	void *scratchbuf;
>  	int ret;
>  
> +	scratchbuf = kmemdup(val, len, GFP_KERNEL);
> +	if (!scratchbuf)
> +		return -ENOMEM;
> +
> +	op.data.buf.in = scratchbuf;
>  	ret = spi_mem_exec_op(flash->spimem, &op);
>  	if (ret < 0)
>  		dev_err(&flash->spimem->spi->dev, "error %d reading %x\n", ret,
>  			code);
>  
> +	kfree(scratchbuf);
> +
>  	return ret;
>  }
>  
> @@ -56,9 +64,19 @@ static int m25p80_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
>  	struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 1),
>  					  SPI_MEM_OP_NO_ADDR,
>  					  SPI_MEM_OP_NO_DUMMY,
> -					  SPI_MEM_OP_DATA_OUT(len, buf, 1));
> +					  SPI_MEM_OP_DATA_OUT(len, NULL, 1));
> +	void *scratchbuf;
> +	int ret;
>  
> -	return spi_mem_exec_op(flash->spimem, &op);
> +	scratchbuf = kmemdup(buf, len, GFP_KERNEL);
> +	if (!scratchbuf)
> +		return -ENOMEM;
> +
> +	op.data.buf.out = scratchbuf;
> +	ret = spi_mem_exec_op(flash->spimem, &op);
> +	kfree(scratchbuf);
> +
> +	return ret;
>  }
>  
>  static ssize_t m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
Jarkko Nikula Sept. 17, 2018, 2:13 p.m. | #2
On 09/17/2018 04:36 PM, Boris Brezillon wrote:
> As documented in spi-mem.h, spi_mem_op->data.buf.{in,out} must be
> DMA-able, and commit 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx()
> API") failed to follow this rule as buffers passed to
> ->{read,write}_reg() are usually placed on the stack.
> 
> Fix that by allocating a scratch buffer and copying the data in there
> before passing it to the spi-mem layer.
> 
> Fixes: 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx() API")
> Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> ---
> Note that the ->{read,write}() path is still buggy since nothing
> guarantees that buffers passed by the MTD layer to the SPI NOR layer
> are DMA-able, but this is a long-standing issue which we'll have to
> address at the spi-nor level (this layer can choose the bounce buffer
> size based on nor->page_size).
> ---
>   drivers/mtd/devices/m25p80.c | 24 +++++++++++++++++++++---
>   1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index cbfafc453274..3b7fafa4bbd6 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -39,14 +39,22 @@ static int m25p80_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
>   	struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
>   					  SPI_MEM_OP_NO_ADDR,
>   					  SPI_MEM_OP_NO_DUMMY,
> -					  SPI_MEM_OP_DATA_IN(len, val, 1));
> +					  SPI_MEM_OP_DATA_IN(len, NULL, 1));
> +	void *scratchbuf;
>   	int ret;
>   
> +	scratchbuf = kmemdup(val, len, GFP_KERNEL);
> +	if (!scratchbuf)
> +		return -ENOMEM;
> +
> +	op.data.buf.in = scratchbuf;
>   	ret = spi_mem_exec_op(flash->spimem, &op);
>   	if (ret < 0)
>   		dev_err(&flash->spimem->spi->dev, "error %d reading %x\n", ret,
>   			code);
>   
> +	kfree(scratchbuf);
> +

Actually this makes things even worse: "unrecognized JEDEC id bytes: b1, 
74, 01" since we don't copy scratchbuf to original buffer and kmemdup 
before bus read is needless :-)
Boris Brezillon Sept. 17, 2018, 2:22 p.m. | #3
On Mon, 17 Sep 2018 17:13:32 +0300
Jarkko Nikula <jarkko.nikula@linux.intel.com> wrote:

> On 09/17/2018 04:36 PM, Boris Brezillon wrote:
> > As documented in spi-mem.h, spi_mem_op->data.buf.{in,out} must be
> > DMA-able, and commit 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx()
> > API") failed to follow this rule as buffers passed to  
> > ->{read,write}_reg() are usually placed on the stack.  
> > 
> > Fix that by allocating a scratch buffer and copying the data in there
> > before passing it to the spi-mem layer.
> > 
> > Fixes: 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx() API")
> > Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> > ---
> > Note that the ->{read,write}() path is still buggy since nothing
> > guarantees that buffers passed by the MTD layer to the SPI NOR layer
> > are DMA-able, but this is a long-standing issue which we'll have to
> > address at the spi-nor level (this layer can choose the bounce buffer
> > size based on nor->page_size).
> > ---
> >   drivers/mtd/devices/m25p80.c | 24 +++++++++++++++++++++---
> >   1 file changed, 21 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> > index cbfafc453274..3b7fafa4bbd6 100644
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > @@ -39,14 +39,22 @@ static int m25p80_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
> >   	struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
> >   					  SPI_MEM_OP_NO_ADDR,
> >   					  SPI_MEM_OP_NO_DUMMY,
> > -					  SPI_MEM_OP_DATA_IN(len, val, 1));
> > +					  SPI_MEM_OP_DATA_IN(len, NULL, 1));
> > +	void *scratchbuf;
> >   	int ret;
> >   
> > +	scratchbuf = kmemdup(val, len, GFP_KERNEL);
> > +	if (!scratchbuf)
> > +		return -ENOMEM;
> > +
> > +	op.data.buf.in = scratchbuf;
> >   	ret = spi_mem_exec_op(flash->spimem, &op);
> >   	if (ret < 0)
> >   		dev_err(&flash->spimem->spi->dev, "error %d reading %x\n", ret,
> >   			code);
> >   
> > +	kfree(scratchbuf);
> > +  
> 
> Actually this makes things even worse: "unrecognized JEDEC id bytes: b1, 
> 74, 01" since we don't copy scratchbuf to original buffer and kmemdup 
> before bus read is needless :-)

True :-).

I'll fix that and send a v2.

Patch

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index cbfafc453274..3b7fafa4bbd6 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -39,14 +39,22 @@  static int m25p80_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
 	struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
 					  SPI_MEM_OP_NO_ADDR,
 					  SPI_MEM_OP_NO_DUMMY,
-					  SPI_MEM_OP_DATA_IN(len, val, 1));
+					  SPI_MEM_OP_DATA_IN(len, NULL, 1));
+	void *scratchbuf;
 	int ret;
 
+	scratchbuf = kmemdup(val, len, GFP_KERNEL);
+	if (!scratchbuf)
+		return -ENOMEM;
+
+	op.data.buf.in = scratchbuf;
 	ret = spi_mem_exec_op(flash->spimem, &op);
 	if (ret < 0)
 		dev_err(&flash->spimem->spi->dev, "error %d reading %x\n", ret,
 			code);
 
+	kfree(scratchbuf);
+
 	return ret;
 }
 
@@ -56,9 +64,19 @@  static int m25p80_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
 	struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 1),
 					  SPI_MEM_OP_NO_ADDR,
 					  SPI_MEM_OP_NO_DUMMY,
-					  SPI_MEM_OP_DATA_OUT(len, buf, 1));
+					  SPI_MEM_OP_DATA_OUT(len, NULL, 1));
+	void *scratchbuf;
+	int ret;
 
-	return spi_mem_exec_op(flash->spimem, &op);
+	scratchbuf = kmemdup(buf, len, GFP_KERNEL);
+	if (!scratchbuf)
+		return -ENOMEM;
+
+	op.data.buf.out = scratchbuf;
+	ret = spi_mem_exec_op(flash->spimem, &op);
+	kfree(scratchbuf);
+
+	return ret;
 }
 
 static ssize_t m25p80_write(struct spi_nor *nor, loff_t to, size_t len,