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. I don't know the details and didn't find any problems with it that a plain request_irq doesn't have. But I wonder about the details and if others are aware of the possible problems. Mark, maybe you can describe in more detail the downsides you see? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
