From patchwork Fri Oct 21 16:20:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukas Wunner X-Patchwork-Id: 9389607 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EFA3460762 for ; Fri, 21 Oct 2016 16:19:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E10652A199 for ; Fri, 21 Oct 2016 16:19:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D56952A1AD; Fri, 21 Oct 2016 16:19:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 05D922A199 for ; Fri, 21 Oct 2016 16:19:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935176AbcJUQTr (ORCPT ); Fri, 21 Oct 2016 12:19:47 -0400 Received: from mailout3.hostsharing.net ([176.9.242.54]:37779 "EHLO mailout3.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935179AbcJUQTo (ORCPT ); Fri, 21 Oct 2016 12:19:44 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout3.hostsharing.net (Postfix) with ESMTPS id 4C9C3100FBE03; Fri, 21 Oct 2016 18:19:37 +0200 (CEST) Received: from localhost (3-38-90-81.adsl.cmo.de [81.90.38.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by h08.hostsharing.net (Postfix) with ESMTPSA id DF3776031F9A; Fri, 21 Oct 2016 18:19:35 +0200 (CEST) Date: Fri, 21 Oct 2016 18:20:10 +0200 From: Lukas Wunner To: Keith Busch Cc: linux-pci@vger.kernel.org, Bjorn Helgaas , Ralf Baechle , Wei Zhang , Andreas Noever Subject: Re: [PATCHv3 2/5] pci: Add is_removed state Message-ID: <20161021162010.GB4221@wunner.de> References: <1475007815-28354-1-git-send-email-keith.busch@intel.com> <1475007815-28354-3-git-send-email-keith.busch@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1475007815-28354-3-git-send-email-keith.busch@intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Sep 27, 2016 at 04:23:32PM -0400, Keith Busch wrote: > This adds a new state for devices that were once in the system, but > unexpectedly removed. This is so device tear down functions can observe > the device is not accessible so it may skip attempting to initialize > the hardware. [...] > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -337,6 +337,7 @@ struct pci_dev { > unsigned int multifunction:1;/* Part of multi-function device */ > /* keep track of device state */ > unsigned int is_added:1; > + unsigned int is_removed:1; /* device was surprise removed */ > unsigned int is_busmaster:1; /* device is busmaster */ > unsigned int no_msi:1; /* device may not use msi */ > unsigned int no_64bit_msi:1; /* device may only use 32-bit MSIs */ The tg3 driver (as well as many other drivers) already check reachability of a device before accessing its mmio space by calling pci_channel_offline(). I've found that the following simple change on top of your series is already sufficient to make hot-removal of the Apple Gigabit Ethernet adapter "just work" (no more soft lockups, which is a giant improvement): This got me thinking: We've got three pci_channel_state values defined in include/linux/pci.h, "normal", "frozen" and "perm_failure". Instead of adding a new "is_removed" bit to struct pci_dev, would it perhaps make more sense to just add a new type of pci_channel_state for removed devices? Then the above change to pci_channel_offline() wouldn't even be necessary. The pciehp and dpc drivers would just change the channel status to "removed" and all the drivers already querying it with pci_channel_offline() would pick up the change automatically. Thoughts? Thanks, Lukas --- 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 diff --git a/include/linux/pci.h b/include/linux/pci.h index 5c43012..cc8b234 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -406,7 +406,7 @@ struct pci_dev *pci_alloc_dev(struct pci_bus *bus); static inline int pci_channel_offline(struct pci_dev *pdev) { - return (pdev->error_state != pci_channel_io_normal); + return pdev->error_state != pci_channel_io_normal || pdev->is_removed; } struct pci_host_bridge {