On Thu, Aug 24, 2017 at 02:10:52PM -0700, Dmitry Torokhov wrote: > On Thu, Aug 24, 2017 at 1:21 PM, Bjorn Helgaas <helgaas at kernel.org> wrote: > > [+cc Tejun, Dmitry, Michael, Stephen, linux-clk for devm/clk questions] > > > > On Wed, Aug 23, 2017 at 03:02:38PM +0800, Shawn Lin wrote: > >> With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine > >> would still access the irq handler registed as a shard irq. > >> Per the comment within the function of __free_irq, it says > >> "It's a shared IRQ -- the driver ought to be prepared for > >> an IRQ event to happen even now it's being freed". However > >> when failing to probe the driver, it may disable the clock > >> for accessing the register and the following check for shared > >> irq state would call the irq handler which accesses the register > >> w/o the clk enabled. That will hang the system forever. Side note: why is this driver even requesting a shared IRQ? This is for rk3399, and the IRQ is a dedicated GIC interrupt for the PCIe controller. It shouldn't need to be 'shared'. The problem still might not be *only* theoretical though, since it's still possible for this non-shared interrupt to (a) trigger (b) concurrently, we remove/tear down (including disable clocks) (c) we service the IRQ <-- dead, because clock is disabled (d) if we ever got here... free_irq() Brian
