From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jingoo Han Subject: Re: [PATCH 01/13] i2c: bcm2835: Use devm_request_irq() Date: Wed, 18 Dec 2013 13:15:42 +0900 Message-ID: <000601cefba7$d13450e0$739cf2a0$%han@samsung.com> References: <001601cefaf3$940d0040$bc2700c0$%han@samsung.com> <001d01cefaf3$b743e4c0$25cbae40$%han@samsung.com> <52B10691.2010105@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <52B10691.2010105-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> Content-language: ko Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: 'Stephen Warren' , 'Wolfram Sang' Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 'Jingoo Han' List-Id: linux-i2c@vger.kernel.org On Wednesday, December 18, 2013 11:21 AM, Stephen Warren wrote: > On 12/16/2013 11:46 PM, Jingoo Han wrote: > > Use devm_request_irq() to make cleanup paths simpler. > > This may not be safe. The interrupt used by the I2C controllers on the > BCM2835 chip is shared between two controllers. In theory, you could run > into a condition where you're remove()ing the driver for one of the > controller (a), while the driver for controller (b) is still active, yet > the HW for controller (a) comes along and triggers an interrupt after > remove() but before the devm IRQ cleanup. That would result in the IRQ > handler for controller (a) executing after the remove() of the > associated device, which could cause a variety of problems. Hi Stephen, I appreciate you detailed and kind description. :-) If there is possible side effect, the patch should not be merged. Wolfram Sang, Please ignore this patch. Thank you. Best regards, Jingoo Han > You might be able to make this safe by explicitly clearing any IRQ > enable registers in remove(), but leaving the code using plain > request_irq() might be simpler.