summaryrefslogtreecommitdiffstats
path: root/.mailmap
diff options
context:
space:
mode:
authorMiquel Raynal2018-12-11 18:38:28 +0100
committerMiquel Raynal2018-12-15 14:49:25 +0100
commitcafb56dd741e61c99709bcd2b193a9a1d36def3b (patch)
treeb0861892672b503bd0226ca587de2efe6f234e07 /.mailmap
parentmtd: rawnand: omap2: Pass the parent of pdev to dma_request_chan() (diff)
downloadkernel-qcow2-linux-cafb56dd741e61c99709bcd2b193a9a1d36def3b.tar.gz
kernel-qcow2-linux-cafb56dd741e61c99709bcd2b193a9a1d36def3b.tar.xz
kernel-qcow2-linux-cafb56dd741e61c99709bcd2b193a9a1d36def3b.zip
mtd: rawnand: marvell: prevent timeouts on a loaded machine
marvell_nfc_wait_op() waits for completion during 'timeout_ms' milliseconds before throwing an error. While the logic is fine, the value of 'timeout_ms' is given by the core and actually correspond to the maximum time the NAND chip will take to complete the operation. Assuming there is no overhead in the propagation of the interrupt signal to the the NAND controller (through the Ready/Busy line), this delay does not take into account the latency of the operating system. For instance, for a page write, the delay given by the core is rounded up to 1ms. Hence, when the machine is over loaded, there is chances that this timeout will be reached. There are two ways to solve this issue that are not incompatible: 1/ Enlarge the timeout value (if so, how much?). 2/ Check after the waiting method if we did not miss any interrupt because of the OS latency (an interrupt is still pending). In this case, we assume the operation exited successfully. We choose the second approach that is a must in all cases, with the possibility to also modify the timeout value to be, e.g. at least 1 second in all cases. Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions