aboutsummaryrefslogtreecommitdiff
path: root/firmware/emi26
diff options
context:
space:
mode:
authorDoug Anderson2014-12-02 15:42:47 -0800
committerUlf Hansson2015-01-19 09:56:05 +0100
commitf8c58c1136349fdfa9b605c501f2f911622d3a9a (patch)
tree3f214e01a5ff8a1715dc8835a44406116146ef60 /firmware/emi26
parentb24c8b260189fe21cca992d2f5175a33f6cc5477 (diff)
mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock
We're running into cases where our enabling of the SDIO interrupt in dw_mmc doesn't actually take effect. Specifically, adding patch like this: +++ b/drivers/mmc/host/dw_mmc.c @@ -1076,6 +1076,9 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb) mci_writel(host, INTMASK, (int_mask | SDMMC_INT_SDIO(slot->id))); + int_mask = mci_readl(host, INTMASK); + if (!(int_mask & SDMMC_INT_SDIO(slot->id))) + dev_err(&mmc->class_dev, "failed to enable sdio irq\n"); } else { ...actually triggers the error message. That's because the dw_mci_enable_sdio_irq() unsafely does a read-modify-write of the INTMASK register. We can't just use the standard host->lock since that lock is not irq safe and mmc_signal_sdio_irq() (called from interrupt context) calls dw_mci_enable_sdio_irq(). Add a new irq-safe lock to protect INTMASK. An alternate solution to this is to punt mmc_signal_sdio_irq() to the tasklet and then protect INTMASK modifications by the standard host lock. This seemed like a bit more of a high-latency change. Reported-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Diffstat (limited to 'firmware/emi26')
0 files changed, 0 insertions, 0 deletions