Hi Michal,
On 1/6/20 3:16 PM, Michal Simek wrote:
On 26. 12. 19 6:44, quanyang.w...@windriver.com wrote:
From: Quanyang Wang <quanyang.w...@windriver.com>
In spi_nor_spimem_xfer_data, it will limit the transfer size
according to nor->bouncebuf_size which is usually equal to
PAGE_SIZE. This means that sometimes a spi_nor_read operation
will be split into several spi_nor_read_data operations if
the transfer size is bigger than PAGE_SIZE .
Considering the case above, when is_ofst_odd is 0, we initialize
the "ptr" to be the "buf" and pass "ptr" as the argument to
spi_nor_read_data, the "ptr" should be updated as the "buf"
after spi_nor_read_data is called, or else the receive data
will be stored in the same place every time.
Signed-off-by: Quanyang Wang <quanyang.w...@windriver.com>
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 79f6a6f4445d..1df42dbc1197 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -3016,6 +3016,8 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t
from, size_t len,
*retlen += ret;
}
buf += ret;
+ if (!is_ofst_odd)
+ ptr += ret;
from += ret;
len -= ret;
}
Is this in code changed by xilinx? Or is this mainline code which should
be also fixed?
This is in code changed by xilinx, and mainline code doesn't have this
change.
The "ptr" is introduced in the commit as below in xlnx_rebase_v4.19_2019.2:
commit 4425351699dcfa44b2307d4d0891aab3e7c7e70a
Author: Naga Sureshkumar Relli <naga.sureshkumar.re...@xilinx.com>
Date: Fri Sep 20 04:51:42 2019 -0600
mtd: spi-nor: Fix incorrect buffer access
Thanks,
Quanyang
Thanks,
Michal
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8284):
https://lists.yoctoproject.org/g/linux-yocto/message/8284
Mute This Topic: https://lists.yoctoproject.org/mt/69268741/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
