On Tue, Jul 30, 2013 at 10:04:29PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.este...@freescale.com>
>
> 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.este...@freescale.com>
> ---
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
