On 9 March 2018 at 19:49, James Hogan <jhogan@xxxxxxxxxx> wrote: > On Fri, Mar 09, 2018 at 12:12:14PM -0300, Ezequiel Garcia wrote: >> From: Alex Smith <alex.smith@xxxxxxxxxx> >> >> A spinlock is held while updating the internal copy of the IRQ mask, >> but not while writing it to the actual IMASK register. After the lock >> is released, an IRQ can occur before the IMASK register is written. >> If handling this IRQ causes the mask to be changed, when the handler >> returns back to the middle of the first mask update, a stale value >> will be written to the mask register. >> >> If this causes an IRQ to become unmasked that cannot have its status >> cleared by writing a 1 to it in the IREG register, e.g. the SDIO IRQ, >> then we can end up stuck with the same IRQ repeatedly being fired but >> not handled. Normally the MMC IRQ handler attempts to clear any >> unexpected IRQs by writing IREG, but for those that cannot be cleared >> in this way then the IRQ will just repeatedly fire. >> >> This was resulting in lockups after a while of using Wi-Fi on the >> CI20 (GitHub issue #19). >> >> Resolve by holding the spinlock until after the IMASK register has >> been updated. >> > > Maybe have a Link tag instead of referencing "github issue #19", i.e.: > Link: https://github.com/MIPS/CI20_linux/issues/19 > > Since this fixes an older commit, it'd be worth adding: > > Fixes: 61bfbdb85687 ("MMC: Add support for the controller on JZ4740 SoCs.") > >> Signed-off-by: Alex Smith <alex.smith@xxxxxxxxxx> > > ... and presumably is worthy of backporting (the driver was introduced > in 2.6.36), i.e.: > Cc: stable@xxxxxxxxxxxxxxx > Oh, yes, good catch. I've overlooked this commit. Thanks, -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar
