Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2186618imm; Thu, 7 Jun 2018 06:49:10 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ+0xR6/zL4c59puJejoJdcR+xzM22NM01NPh/mCAQYac+9SlPIcr4Clhpkgveonsyu45KH X-Received: by 2002:a63:a84f:: with SMTP id i15-v6mr1726022pgp.422.1528379350070; Thu, 07 Jun 2018 06:49:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528379350; cv=none; d=google.com; s=arc-20160816; b=xyw+LnBflYOv6OLC+e6OIZgsiAnpghG+RD//BcUBItWHCQtciuxqF3l7YjrGCkBHHd krDbgyElPJQJz+SagnGLzF8e0fzgDVoxF9/xfb6+IVDvfPpTUIUsZpePxkSILtMgm989 ZNzjKP/vxp5I/OhQwLRPA3ZU0lY1TWkjOUjhIfqFpM+Y76PdQjPravFLI6WIm7CvFV/j 3HyHV/1ooBmIcXHYLoDagNaK1hs/hV068qHinqTrnot/nqiMowp1HaiCDh7BfuQTg7DV OLdMVzB7E/xXIN8SUVkm1PQfhraO0f1V47V5ruR5A89sucZxoKb7S/jKOOR0epVOd2/Q IDDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=fN/XDeySKCYQZVZC3l0AKUtvFaBc4cixi3cgt/Xo6aw=; b=lQG1xIK9JcotE14NGHaHrSYc3wfTT1i4C6BKKnYgfMG1komDWFJ37OxD4BmC1dBm/i +xBEB5+qm41SH5RhCwyVzHQDQY7otnJxHb0AU0uCMRgnc/HgPdiwoFyvSNAsxvYMB0h/ ErCzBaKykfW7iT63gKFQFsDgjZmb1u3aAerNonuq0jvVYM1i//bWbREcPt3KsERdRV/k HFNKEnoTU+zsbz0nI5Jsfuo7169Fbqb534XSLGX39ssOEkyvZqB/JgFK+3noiAnrz0GE +il7hXI4vT4QAFz4Z/kbNR+8YecuZ52AOMYNtvnvMFoIHoDf4ckLZPd/SYb+xatm7lIG EKiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=cqE7COVh; dkim=pass header.i=@codeaurora.org header.s=default header.b=oowlkLz/; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e12-v6si8463764pgu.267.2018.06.07.06.48.55; Thu, 07 Jun 2018 06:49:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=cqE7COVh; dkim=pass header.i=@codeaurora.org header.s=default header.b=oowlkLz/; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932630AbeFGNsO (ORCPT + 99 others); Thu, 7 Jun 2018 09:48:14 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:56286 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932152AbeFGNsL (ORCPT ); Thu, 7 Jun 2018 09:48:11 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 84078607E7; Thu, 7 Jun 2018 13:48:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1528379290; bh=aMGTZV/Txs5XiGLVGoXCYibwqxR03GdV/Rl9O06xyxo=; h=Date:From:To:Subject:In-Reply-To:References:From; b=cqE7COVhSF9dxekCZr22uGxF3/Ie1APFykzWMXSFpW0aLoOolwnfye0rTL7ncRuFP qPnZrH1yeHhEvB17QIc70SdhOuBWBVAmLd8Rkx+z+MCXrPhbs7MgKgePXxCH7pSmM7 LjWtGw6Wcc6PEvI58RCe8+B943Q8O3aTvuiWO8jg= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id B758F601B4; Thu, 7 Jun 2018 13:48:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1528379283; bh=aMGTZV/Txs5XiGLVGoXCYibwqxR03GdV/Rl9O06xyxo=; h=Date:From:To:Subject:In-Reply-To:References:From; b=oowlkLz/a5YXibHHw/tLicNJCf3LRsMt04MeaEEYaaVccbUbDuEOyHRpzpS3Dl5Na JO/cay/nKkmeXAsfIaSH9cIrJ68LenyptEP1Z4R53NPV1oXs7Wd2Rpb/QsX3f1Y9d1 NL1GRIc2HiYhRqDo7sksFZ+3x0eHZxqfKrcjLyNs= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Jun 2018 19:18:03 +0530 From: poza@codeaurora.org To: Bjorn Helgaas , Philippe Ombredanne , Thomas Gleixner , Greg Kroah-Hartman , Kate Stewart , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Dongdong Liu , Keith Busch , Wei Zhang , Sinan Kaya , Timur Tabi Subject: Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset() In-Reply-To: <1528351234-26914-6-git-send-email-poza@codeaurora.org> References: <1528351234-26914-1-git-send-email-poza@codeaurora.org> <1528351234-26914-6-git-send-email-poza@codeaurora.org> Message-ID: <94661add3e71e3694aa22c2a9cabf503@codeaurora.org> X-Sender: poza@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-06-07 11:30, Oza Pawandeep wrote: > We are handling ERR_FATAL by resetting the Link in software,skipping > the > driver pci_error_handlers callbacks, removing the devices from the PCI > subsystem, and re-enumerating, as a result of that, no more calling > pcie_portdrv_slot_reset in ERR_FATAL case. > > Signed-off-by: Oza Pawandeep > > diff --git a/drivers/pci/pcie/portdrv_pci.c > b/drivers/pci/pcie/portdrv_pci.c > index 973f1b8..92f5d330 100644 > --- a/drivers/pci/pcie/portdrv_pci.c > +++ b/drivers/pci/pcie/portdrv_pci.c > @@ -42,17 +42,6 @@ __setup("pcie_ports=", pcie_port_setup); > > /* global data */ > > -static int pcie_portdrv_restore_config(struct pci_dev *dev) > -{ > - int retval; > - > - retval = pci_enable_device(dev); > - if (retval) > - return retval; > - pci_set_master(dev); > - return 0; > -} > - > #ifdef CONFIG_PM > static int pcie_port_runtime_suspend(struct device *dev) > { > @@ -162,14 +151,6 @@ static pci_ers_result_t > pcie_portdrv_mmio_enabled(struct pci_dev *dev) > > static pci_ers_result_t pcie_portdrv_slot_reset(struct pci_dev *dev) > { > - /* If fatal, restore cfg space for possible link reset at upstream */ > - if (dev->error_state == pci_channel_io_frozen) { > - dev->state_saved = true; > - pci_restore_state(dev); > - pcie_portdrv_restore_config(dev); > - pci_enable_pcie_error_reporting(dev); > - } > - > return PCI_ERS_RESULT_RECOVERED; > } Hi Bjorn, the above patch removes ERR_FATAL handling from pcie_portdrv_slot_reset() because now we are handling ERR_FATAL differently than before. I tried to dig into pcie_portdrv_slot_reset() handling for ERR_FATAL case where it restores the config space, enable device, set master and enable error reporting.... and as far as I understand this is being done for upstream link (bridges etc..) why was it done at the first point (I checked the commit description, but could not really get it) and do we need to handle the same thing in ERR_FATAL now ? Regards, Oza.