Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752424AbbHZT34 (ORCPT ); Wed, 26 Aug 2015 15:29:56 -0400 Received: from mail-la0-f47.google.com ([209.85.215.47]:36135 "EHLO mail-la0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751585AbbHZT3y convert rfc822-to-8bit (ORCPT ); Wed, 26 Aug 2015 15:29:54 -0400 MIME-Version: 1.0 In-Reply-To: <20150825195830.GH27534@saruman.tx.rr.com> References: <20150825195830.GH27534@saruman.tx.rr.com> Date: Wed, 26 Aug 2015 16:29:52 -0300 Message-ID: Subject: Re: CONFIG_DEBUG_SHIRQ and PM From: Ezequiel Garcia To: Felipe Balbi Cc: Ingo Molnar , Tony Lindgren , Linux OMAP Mailing List , Linux Kernel Mailing List , Linux ARM Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2427 Lines: 59 Felipe, On 25 August 2015 at 16:58, Felipe Balbi wrote: > Hi Ingo, > > I'm facing an issue with CONFIG_DEBUG_SHIRQ and pm_runtime when using > devm_request_*irq(). > I may be jumping on the gun here, but I believe here's your problem. Using devm_request_irq with shared IRQs is not a good idea. Or at least, it forces you to handle interrupts after your device is _completely_ removed (e.g. your IRQ cookie could be bogus). AFAICS, the CONFIG_DEBUG_SHIRQ option is just triggering a couple spurious interrupts, that are expected to happen anyway. Your IRQ is shared, and so you may get any IRQ at any time, coming from another device (not yours). So, if I'm right, my suggestion is simple: use request_irq/free_irq and free your IRQ before you disable your clocks, remove your device, etc. > If we using devm_request_*irq(), that irq will be freed after device > drivers' ->remove() gets called. If on ->remove(), we're calling > pm_runtime_put_sync(); pm_runtime_disable(), device's clocks might get > gated and, because we do an extra call to the device's IRQ handler when > CONFIG_DEBUG_SHIRQ=y, we might trigger an abort exception if, inside the > IRQ handler, we try to read a register which is clocked by the device's > clock. > > This is, of course, really old code which has been in tree for many, > many years. I guess nobody has been running their tests in the setup > mentioned above (CONFIG_DEBUG_SHIRQ=y, pm_runtime_put_sync() on > ->remove(), a register read on IRQ handler, and a shared IRQ handler), > so that's why we never caught this before. > > Disabling CONFIG_DEBUG_SHIRQ, of course, makes the problem go away, but > if driver *must* be ready to receive, and handle, an IRQ even during > module removal, I wonder what the IRQ handler should do. We can't, in > most cases, call pm_runtime_put_sync() from IRQ handler. > > I'm guessing the only way would be to move pm_runtime calls into the bus > driver (in this case, the platform_bus) and make sure it only gets > called after device managed resources are freed ? > > Any hints would be greatly appreciated. > Hope it helps! -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/