On Wed, Jul 31, 2013 at 10:05:12AM +0100, Mark Brown wrote: > On Wed, Jul 31, 2013 at 10:46:45AM +0200, Uwe Kleine-König wrote: > > > OK, so the possible problem is that remove is called while the irq is > > still active. That means you have to assert that all resources the irq > > handler is using (e.g. ioremap, clk_prepare_enable) are only freed > > *after* the irq is done. For ioremap that means it must be done using > > devm_ioremap_resource. For a clock it's not that easy because the irq > > handler has to assert that a used clk is kept prepared which can only be > > done using clk_prepare which in turn is not allowed in an irq handler. > > > Hmm. So the only possible fixes are > > - devm* can be told to also care about clk_disable_unprepare > > - after disabling irqs in the remove callback wait for all > > active irqs to be done. (i.e. call synchronize_irq(irq)) > > - don't use devm_request_irq > > I'm not sure that devm_ guarantees any ordering in the cleanups it does > so I'd not like to rely on the first option either, if there were some > guarantee of that it'd help. The nice thing about explicitly freeing > the IRQ is that you can tell that all this stuff is safe by inspection. Yes, agree, driver knows when to call free_irq safely, besides, free_irq can be at the beginnig of removal but not at last of removal, just like we always request_irq at the last of probe (after hardware initialization has finished). -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
