On Wed, Jul 31, 2013 at 09:33:06AM +0200, Uwe Kleine-König wrote: > On Tue, Jul 30, 2013 at 10:04:29PM -0300, Fabio Estevam wrote: > > From: Fabio Estevam <fabio.estevam@xxxxxxxxxxxxx> > > > > By using devm_request_irq() we don't need to call free_irq(), which simplifies > > the code a bit. > > > > Signed-off-by: Fabio Estevam <fabio.estevam@xxxxxxxxxxxxx> > > --- > > drivers/usb/chipidea/core.c | 6 ++---- > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > > index 5cc1b02..d185c41 100644 > > --- a/drivers/usb/chipidea/core.c > > +++ b/drivers/usb/chipidea/core.c > > @@ -502,8 +502,8 @@ static int ci_hdrc_probe(struct platform_device *pdev) > > } > > > > platform_set_drvdata(pdev, ci); > > - ret = request_irq(ci->irq, ci_irq, IRQF_SHARED, ci->platdata->name, > > - ci); > > + ret = devm_request_irq(dev, ci->irq, ci_irq, IRQF_SHARED, > > + ci->platdata->name, ci); > Mark Brown (now on Cc:) replied to one of my patches using > devm_request_irq: > > I'm always deeply suspicous of devm_request_irq() since you need > to be *very* sure that the interrupt can't fire during cleanup > and cause the handlers to try to use data structures that are > already being freed. > > and: > > devm_request_threaded_irq() is just generally a bit of a warning > sign since it needs careful checking to tell if it's safe. > The probably problem I find is the free_irq will be called after driver's removal is called, then the problem Mark described will occur. See __device_release_driver(struct device *dev) at drivers/base/dd.c. -- 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
