summaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorBrian Norris <computersforpeace@gmail.com>2016-03-05 02:19:23 +0100
committerBrian Norris <computersforpeace@gmail.com>2016-03-07 22:51:11 +0100
commit9ebfdf5b18493f338237ef9861a555c2f79b0c17 (patch)
tree0e1c2041a5cad1919cca33f3153de9e932bec986 /fs
parentmtd: bcm63xxpart: give width specifier an 'int', not 'size_t' (diff)
downloadlinux-9ebfdf5b18493f338237ef9861a555c2f79b0c17.tar.xz
linux-9ebfdf5b18493f338237ef9861a555c2f79b0c17.zip
mtd: nand: check status before reporting timeout
In commit b70af9bef49b ("mtd: nand: increase ready wait timeout and report timeouts"), we increased the likelihood of scheduling during nand_wait(). This makes us more likely to hit the time_before(...) condition, since a lot of time may pass before we get scheduled again. Now, the loop was already buggy, since we don't check if the NAND is ready after exiting the loop; we simply print out a timeout warning. Fix this by doing a final status check before printing a timeout message. This isn't actually a critical bug, since the only effect is a false warning print. But too many prints never hurt anyone, did they? :) Side note: perhaps I'm not smart enough, but I'm not sure what the best policy is for this kind of loop; do we busy loop (i.e., no cond_resched()) to keep the lowest I/O latency (it's not great if the resched is delaying Richard's system ~400ms)? Or do we allow rescheduling, to play nice with the rest of the system (since some operations can take quite a while)? Reported-by: Richard Weinberger <richard@nod.at> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Richard Weinberger <richard@nod.at> Reviewed-by: Harvey Hunt <harvey.hunt@imgtec.com>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions