On 08/05/2019 01:38 PM, Vignesh Raghavendra wrote: > External E-Mail > > > > On 05/08/19 2:36 PM, Tudor.Ambarus@xxxxxxxxxxxxx wrote: >> >> >> On 08/01/2019 07:22 PM, Vignesh Raghavendra wrote: >>> External E-Mail >>> >>> >>> spi-mem layer expects all buffers passed to it to be DMA'able. But >>> spi-nor layer mostly allocates buffers on stack for reading/writing to >>> registers and therefore are not DMA'able. Introduce bounce buffer to be >>> used to read/write to registers. This ensures that buffer passed to >>> spi-mem layer during register read/writes is DMA'able. With this change >>> nor->cmd-buf is no longer used, so drop it. >>> >>> Reviewed-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> >>> Signed-off-by: Vignesh Raghavendra <vigneshr@xxxxxx> >>> --- >>> >>> v4: >>> Avoid memcpy during READID >>> >>> v3: new patch >>> >>> drivers/mtd/spi-nor/spi-nor.c | 70 ++++++++++++++++++++--------------- >>> include/linux/mtd/spi-nor.h | 7 +++- >>> 2 files changed, 45 insertions(+), 32 deletions(-) >>> >>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c >>> index 03cc788511d5..e02376e1127b 100644 >>> --- a/drivers/mtd/spi-nor/spi-nor.c >>> +++ b/drivers/mtd/spi-nor/spi-nor.c >> >> cut >> >>> /** >>> @@ -1404,9 +1401,11 @@ static int write_sr_cr(struct spi_nor *nor, u8 *sr_cr) >>> { >>> int ret; >>> >>> + memcpy(nor->bouncebuf, sr_cr, 2); >> >> I'm thinking out loud. This can be avoided by forcing all the callers to use >> nor->bouncebuf. That would result in a: >> > > I can make this change and make all callers use nor->bouncebuf in next > version. > should be ok, it will not change the flow logic. >> static int write_sr(struct spi_nor *nor, size_t len) >> >> write_sr_cr() can be removed. Memcopying 2 bytes is a small price to pay, we can >> keep things as they are, to not be too invasive. But if you think that this idea >> is worth it, tell. >> > > Sounds good to me. But replacing write_sr_cr() with above defintion of > write_sr() should be a patch IMO> I'll do a patch after we finish to integrate the big fat changes. Thanks, ta ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/