summaryrefslogtreecommitdiffstats
path: root/drivers/power/pcf50633-charger.c
diff options
context:
space:
mode:
authorPaul Parsons <lost.distance@yahoo.com>2011-05-15 13:24:41 +0000
committerChris Ball <cjb@laptop.org>2011-07-20 17:21:01 -0400
commite312eb1e66e4357000e4e7438849d5a5fd738219 (patch)
tree92db313b4b90a45bee281de4ebf6b74903812535 /drivers/power/pcf50633-charger.c
parentd6fec69d0da640366e1f0a0df092757d46821b10 (diff)
downloadtalos-obmc-linux-e312eb1e66e4357000e4e7438849d5a5fd738219.tar.gz
talos-obmc-linux-e312eb1e66e4357000e4e7438849d5a5fd738219.zip
mmc: tmio: Fix race condition resulting in spurious interrupts
There is a race condition in the tmio_mmc_irq() interrupt handler, caused by the presence of a while loop, which results in warnings of spurious interrupts. This was found on an HP iPAQ hx4700 whose HTC ASIC3 reportedly incorporates the Toshiba TC6380AF controller. Towards the end of a multiple read (CMD18) operation the handler clears the final RXRDY status bit in the first loop iteration, sees the DATAEND status bit at the bottom of the loop, and so clears the DATAEND status bit in the second loop iteration. However the DATAEND interrupt is still queued in the system somewhere and can't be delivered until the handler has returned. This second interrupt is then reported as spurious in the next call to the handler. Likewise for single read (CMD17) operations. And something similar occurs for multiple write (CMD25) and single write (CMD24) operations, where CMDRESPEND and TXRQ status bits are cleared in a single call. In these cases the interrupt handler clears two separate interrupts when it should only clear the one interrupt for which it was invoked. The fix is to remove the while loop. Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Signed-off-by: Chris Ball <cjb@laptop.org>
Diffstat (limited to 'drivers/power/pcf50633-charger.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud