Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752199AbdHJJOx (ORCPT ); Thu, 10 Aug 2017 05:14:53 -0400 Received: from lucky1.263xmail.com ([211.157.147.131]:47229 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751412AbdHJJOw (ORCPT ); Thu, 10 Aug 2017 05:14:52 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-RL-SENDER: shawn.lin@rock-chips.com X-FST-TO: briannorris@chromium.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: shawn.lin@rock-chips.com X-UNIQUE-TAG: <3e3fff2e1605ed1fb7cc242d0c406617> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Cc: Bjorn Helgaas , Marc Zyngier , Thomas Gleixner , shawn.lin@rock-chips.com, Heiko Stuebner , linux-pci@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, Douglas Anderson , Brian Norris Subject: Re: [RFC PATCH] PCI: rockchip: fix system hang up if activate CONFIG_DEBUG_SHIRQ To: jeffy References: <1502353273-123788-1-git-send-email-shawn.lin@rock-chips.com> <598C1BDF.6010203@rock-chips.com> From: Shawn Lin Message-ID: Date: Thu, 10 Aug 2017 17:14:43 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <598C1BDF.6010203@rock-chips.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1562 Lines: 36 Hi Jeffy On 2017/8/10 16:39, jeffy wrote: > Hi shawn, > > On 08/10/2017 04:21 PM, Shawn Lin wrote: >> With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine >> would still access the irq handler registed as a shard irq. >> Per the comment within the function of __free_irq, it says >> "It's a shared IRQ -- the driver ought to be prepared for >> an IRQ event to happen even now it's being freed". However >> when failing to probe the driver, it may disable the clock >> for accessing the register and the following check for shared >> irq state would call the irq handler which accesses the register >> w/o the clk enabled. That will hang the system forever. > > i think this extra irq call is to make sure it's safe to get a shared > irq when we are freeing it, and we would not get this irq after freed it. > > so maybe just call devm_free_irq before disable clks(and other required > resources for the irq handler)? and also do it in the rockchip_pcie_remove. That works since we free it and the following devm_irq_release would bail out early. But I know sure if it is the real intention of the devm_ irq stuff, although devm_free_irq should be called to free the IRQ separately if we want. At least that is so explicit that folks will know that, as more from the top view, it seems only a little drivers there call devm_free_irq for this case by looking into some more drivers(Still no any PCIe drivers do that). Not sure if their systems are robust enough that could access the register w/o clk, even without power domain enabled. > > >