[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130124123615.GG12933@pengutronix.de>
Date: Thu, 24 Jan 2013 13:36:15 +0100
From: Wolfram Sang <w.sang@...gutronix.de>
To: Julia Lawall <julia.lawall@...6.fr>
Cc: nsekhar@...com, khilman@...com, ben-linux@...ff.org,
grant.likely@...retlab.ca, rob.herring@...xeda.com,
davinci-linux-open-source@...ux.davincidsp.com,
linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree-discuss@...ts.ozlabs.org
Subject: Re: question about drivers/i2c/busses/i2c-davinci.c
On Sun, Jan 06, 2013 at 09:00:59PM +0100, Julia Lawall wrote:
> The function davinci_i2c_remove in drivers/i2c/busses/i2c-davinci.c
> contains the following code:
>
> put_device(&pdev->dev);
>
> clk_disable_unprepare(dev->clk);
> clk_put(dev->clk);
> dev->clk = NULL;
>
> davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, 0);
> free_irq(dev->irq, dev);
>
> Is there any danger in putting free_irq(dev->irq, dev); after
> put_device(&pdev->dev);, because the interrupt handler
> i2c_davinci_isr can eg refer to dev->dev.
Not having a clock doesn't sound exactly thrilling either when servicing
an interrupt. I've seen something like this in the remove path of
another driver today as well. I assume a lot of drivers might have such
issues. It is also one of the subtle issues with devm_request_irq. The
remove path can already render the ISR unusable/oopsable but devm will
free the interrupt only after remove has finished. Interrupts need to be
properly masked out before.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists