user/sven/linux.git/drivers/mtd/chips, branch v4.4.283

mtd: cfi_cmdset_0002: don't free cfi->cfiq in error path of cfi_amdstd_setup()

2020-10-01T09:11:50Z

[ Upstream commit 03976af89e3bd9489d542582a325892e6a8cacc0 ] Else there may be a double-free problem, because cfi->cfiq will be freed by mtd_do_chip_probe() if both the two invocations of check_cmd_set() return failure. Signed-off-by: Hou Tao Reviewed-by: Richard Weinberger Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin

mtd: cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer

2020-05-02T15:20:52Z

commit d9b8a67b3b95a5c5aae6422b8113adc1c2485f2b upstream. In function do_write_buffer(), in the for loop, there is a case chip_ready() returns 1 while chip_good() returns 0, so it never break the loop. To fix this, chip_good() is enough and it should timeout if it stay bad for a while. Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") Signed-off-by: Yi Huaijie Signed-off-by: Liu Jian Reviewed-by: Tokunori Ikegami Signed-off-by: Richard Weinberger Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Use chip_good() to retry in do_write_oneword()

2019-10-05T10:27:37Z

commit 37c673ade35c707d50583b5b25091ff8ebdeafd7 upstream. As reported by the OpenWRT team, write requests sometimes fail on some platforms. Currently to check the state chip_ready() is used correctly as described by the flash memory S29GL256P11TFI01 datasheet. Also chip_good() is used to check if the write is succeeded and it was implemented by the commit fb4a90bfcd6d8 ("[MTD] CFI-0002 - Improve error checking"). But actually the write failure is caused on some platforms and also it can be fixed by using chip_good() to check the state and retry instead. Also it seems that it is caused after repeated about 1,000 times to retry the write one word with the reset command. By using chip_good() to check the state to be done it can be reduced the retry with reset. It is depended on the actual flash chip behavior so the root cause is unknown. Cc: Chris Packham Cc: Joakim Tjernlund Cc: linux-mtd@lists.infradead.org Cc: stable@vger.kernel.org Reported-by: Fabio Bettoni Signed-off-by: Felix Fietkau Signed-off-by: Hauke Mehrtens Signed-off-by: Tokunori Ikegami [vigneshr@ti.com: Fix a checkpatch warning] Signed-off-by: Vignesh Raghavendra Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Change erase functions to check chip good only

2018-07-11T14:03:51Z

commit 79ca484b613041ca223f74b34608bb6f5221724b upstream. Currently the functions use to check both chip ready and good. But the chip ready is not enough to check the operation status. So change this to check the chip good instead of this. About the retry functions to make sure the error handling remain it. Signed-off-by: Tokunori Ikegami Reviewed-by: Joakim Tjernlund Cc: Chris Packham Cc: Brian Norris Cc: David Woodhouse Cc: Boris Brezillon Cc: Marek Vasut Cc: Richard Weinberger Cc: Cyrille Pitchen Cc: linux-mtd@lists.infradead.org Cc: stable@vger.kernel.org Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Change erase functions to retry for error

2018-07-11T14:03:51Z

commit 45f75b8a919a4255f52df454f1ffdee0e42443b2 upstream. For the word write functions it is retried for error. But it is not implemented to retry for the erase functions. To make sure for the erase functions change to retry as same. This is needed to prevent the flash erase error caused only once. It was caused by the error case of chip_good() in the do_erase_oneblock(). Also it was confirmed on the MACRONIX flash device MX29GL512FHT2I-11G. But the error issue behavior is not able to reproduce at this moment. The flash controller is parallel Flash interface integrated on BCM53003. Signed-off-by: Tokunori Ikegami Reviewed-by: Joakim Tjernlund Cc: Chris Packham Cc: Brian Norris Cc: David Woodhouse Cc: Boris Brezillon Cc: Marek Vasut Cc: Richard Weinberger Cc: Cyrille Pitchen Cc: linux-mtd@lists.infradead.org Cc: stable@vger.kernel.org Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Change definition naming to retry write operation

2018-07-11T14:03:51Z

commit 85a82e28b023de9b259a86824afbd6ba07bd6475 upstream. The definition can be used for other program and erase operations also. So change the naming to MAX_RETRIES from MAX_WORD_RETRIES. Signed-off-by: Tokunori Ikegami Reviewed-by: Joakim Tjernlund Cc: Chris Packham Cc: Brian Norris Cc: David Woodhouse Cc: Boris Brezillon Cc: Marek Vasut Cc: Richard Weinberger Cc: Cyrille Pitchen Cc: linux-mtd@lists.infradead.org Cc: stable@vger.kernel.org Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Avoid walking all chips when unlocking.

2018-07-03T09:21:30Z

commit f1ce87f6080b1dda7e7b1eda3da332add19d87b9 upstream. cfi_ppb_unlock() walks all flash chips when unlocking sectors, avoid walking chips unaffected by the unlock operation. Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking") Cc: stable@vger.kernel.org Signed-off-by: Joakim Tjernlund Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Fix unlocking requests crossing a chip boudary

2018-07-03T09:21:30Z

commit 0cd8116f172eed018907303dbff5c112690eeb91 upstream. The "sector is in requested range" test used to determine whether sectors should be re-locked or not is done on a variable that is reset everytime we cross a chip boundary, which can lead to some blocks being re-locked while the caller expect them to be unlocked. Fix the check to make sure this cannot happen. Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking") Cc: stable@vger.kernel.org Signed-off-by: Joakim Tjernlund Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: fix SEGV unlocking multiple chips

2018-07-03T09:21:30Z

commit 5fdfc3dbad099281bf027a353d5786c09408a8e5 upstream. cfi_ppb_unlock() tries to relock all sectors that were locked before unlocking the whole chip. This locking used the chip start address + the FULL offset from the first flash chip, thereby forming an illegal address. Fix that by using the chip offset(adr). Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking") Cc: stable@vger.kernel.org Signed-off-by: Joakim Tjernlund Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Use right chip in do_ppb_xxlock()

2018-07-03T09:21:29Z

commit f93aa8c4de307069c270b2d81741961162bead6c upstream. do_ppb_xxlock() fails to add chip->start when querying for lock status (and chip_ready test), which caused false status reports. Fix that by adding adr += chip->start and adjust call sites accordingly. Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking") Cc: stable@vger.kernel.org Signed-off-by: Joakim Tjernlund Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman