summaryrefslogtreecommitdiffstats
path: root/drivers/staging/zcache
diff options
context:
space:
mode:
authorMatthijs Kooijman2013-04-11 17:52:41 +0200
committerGreg Kroah-Hartman2013-04-11 21:58:39 +0200
commit6706c721b22aadffbffec7550b81efedddd05cfb (patch)
treee763faf21c606750ae874fcd45258744f6fd1116 /drivers/staging/zcache
parentstaging: dwc2: don't pass IRQ_LEVEL to devm_request_irq (diff)
downloadkernel-qcow2-linux-6706c721b22aadffbffec7550b81efedddd05cfb.tar.gz
kernel-qcow2-linux-6706c721b22aadffbffec7550b81efedddd05cfb.tar.xz
kernel-qcow2-linux-6706c721b22aadffbffec7550b81efedddd05cfb.zip
staging: dwc2: register common irq handler in dwc2_core_init
Before, this was initialized in pci.c, after the dwc2_hcd_init was called and the interrupts were enabled. This opened up a small time window where common interrupts could be triggered, but there was no handler for them, causing them to keep triggering infinitely and locking up the machine. On my RT3052 board this bug could be easily reproduced by hardcoding the console log level to 8, so that a bunch of debug output from the dwc2 driver was generated inside this time window. This caused the interrupt lockup to occur almost every time. By requesting the irq inside dwc2_core_init and by disabling interrupts before calling dwc2_core_init instead of after, we can be sure the handler is registered before the interrupts are enabled, which should close this window. Reported-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/staging/zcache')
0 files changed, 0 insertions, 0 deletions