From patchwork Fri Oct 11 23:56:31 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 3029841 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 24E93BF924 for ; Fri, 11 Oct 2013 23:44:51 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2B8A320379 for ; Fri, 11 Oct 2013 23:44:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3F96020351 for ; Fri, 11 Oct 2013 23:44:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753947Ab3JKXos (ORCPT ); Fri, 11 Oct 2013 19:44:48 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:53637 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753911Ab3JKXor (ORCPT ); Fri, 11 Oct 2013 19:44:47 -0400 Received: from afcc125.neoplus.adsl.tpnet.pl [95.49.54.125] (HELO vostro.rjw.lan) by serwer1319399.home.pl [79.96.170.134] with SMTP (IdeaSmtpServer v0.80) id f5b5b651ad2524eb; Sat, 12 Oct 2013 01:44:45 +0200 From: "Rafael J. Wysocki" To: Linus Torvalds , Bjorn Helgaas Cc: Steven Rostedt , LKML , "Rafael J. Wysocki" , Mika Westerberg , Andrew Morton , Linux PCI , ACPI Devel Maling List Subject: Re: [BUG] WARN_ON(!context) in drivers/pci/hotplug/acpiphp_glue.c Date: Sat, 12 Oct 2013 01:56:31 +0200 Message-ID: <4515770.NUXBX1NCHS@vostro.rjw.lan> User-Agent: KMail/4.10.5 (Linux/3.11.0+; KDE/4.10.5; x86_64; ; ) In-Reply-To: <4905498.aEGIofg2fM@vostro.rjw.lan> References: <20131010165905.7815defa@gandalf.local.home> <4905498.aEGIofg2fM@vostro.rjw.lan> MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Friday, October 11, 2013 11:58:48 PM Rafael J. Wysocki wrote: > On Friday, October 11, 2013 10:21:35 AM Linus Torvalds wrote: > > On Fri, Oct 11, 2013 at 4:13 AM, Rafael J. Wysocki wrote: [...] > > Or am I misreading the code? It's more readable, and no longer makes > > me homicidal, but I don't actually know the code itself. > > I think you're reading it correctly, it really makes acpiphp see all slots > even if pciehp sees them too. So the change is somewhat risky. > > That said the risk doesn't seem to be huge and there seem to be cases in > which it actually would be useful to have both acpiphp and pciehp signaling > available for the same device. For example, even if the BIOS told us that > we could use the native mechanism (pciehp), it may not actually work. That is, > we may not get any hotplug interrupts from PCIe ports due to platform bugs of > some sort and we may get ACPI notifications instead (because the platform > designer knew about those bugs and thought it would be smart to use ACPI to > work around them). > > There are bug reports indicating thinks like that, so we were going to allow > acpiphp and pciehp to handle the same devices anyway at one point. I thought > we might as well try to do it now and see how it goes. Still, if you think > it's too risky for this stage of the cycle, I'll just send a patch removing > the WARN_ON() and we'll revisit that thing in 3.13. Having reconsidered this I think it's best to just drop the WARN_ON() for now after all and sort out the coexistence between acpiphp and pciehp later, so that we don't run into a weird corner case late in the cycle. So the one below is what I'm going to do for 3.12. Rafael --- From: Rafael J. Wysocki Subject: ACPI / hotplug / PCI: Drop WARN_ON() from acpiphp_enumerate_slots() The WARN_ON() in acpiphp_enumerate_slots() triggers unnecessarily for devices whose bridges are going to be handled by native PCIe hotplug (pciehp) and the simplest way to prevent that from happening is to drop the WARN_ON(). References: https://bugzilla.kernel.org/show_bug.cgi?id=62831 Reported-by: Steven Rostedt Signed-off-by: Rafael J. Wysocki --- drivers/pci/hotplug/acpiphp_glue.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c =================================================================== --- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c +++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c @@ -999,12 +999,13 @@ void acpiphp_enumerate_slots(struct pci_ /* * This bridge should have been registered as a hotplug function - * under its parent, so the context has to be there. If not, we - * are in deep goo. + * under its parent, so the context should be there, unless the + * parent is going to be handled by pciehp, in which case this + * bridge is not interesting to us either. */ mutex_lock(&acpiphp_context_lock); context = acpiphp_get_context(handle); - if (WARN_ON(!context)) { + if (!context) { mutex_unlock(&acpiphp_context_lock); put_device(&bus->dev); kfree(bridge);