mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop
authorDouglas Anderson <dianders@chromium.org>
Mon, 13 Apr 2020 23:27:27 +0000 (16:27 -0700)
committerUlf Hansson <ulf.hansson@linaro.org>
Mon, 20 Apr 2020 07:24:39 +0000 (09:24 +0200)
commitb1ac62a7ac386d76968af5f374a4a7a82a35fe31
treee826e29b7864bf47670a7361b097b07f8582e636
parentddca1092c4324c89cf692b5efe655aa251864b51
mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop

Open-coding a timeout loop invariably leads to errors with handling
the timeout properly in one corner case or another.  In the case of
cqhci we might report "CQE stuck on" even if it wasn't stuck on.
You'd just need this sequence of events to happen in cqhci_off():

1. Call ktime_get().
2. Something happens to interrupt the CPU for > 100 us (context switch
   or interrupt).
3. Check time and; set "timed_out" to true since > 100 us.
4. Read CQHCI_CTL.
5. Both "reg & CQHCI_HALT" and "timed_out" are true, so break.
6. Since "timed_out" is true, falsely print the error message.

Rather than fixing the polling loop, use readx_poll_timeout() like
many people do.  This has been time tested to handle the corner cases.

Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200413162717.1.Idece266f5c8793193b57a1ddb1066d030c6af8e0@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
drivers/mmc/host/cqhci.c