Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp17119pxk; Tue, 22 Sep 2020 17:07:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbUUGEVIBZxHqxvuTaKQRGGvsDWPNTVcpYao9TPFV7gfv8N6TlSC6or07iaRpGaL/pzdC9 X-Received: by 2002:a17:906:aacb:: with SMTP id kt11mr7580482ejb.294.1600819645511; Tue, 22 Sep 2020 17:07:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600819645; cv=none; d=google.com; s=arc-20160816; b=xMR91tSNBByFJlxP60DQG+Y4EGZl1X9KpBtEgWMYeB3KR95zmgWCGJjs/J4L17UEUm hUp9QnFavK/9nCxZIb3C2sb8wO1ebUiNQ/B4qLWQPf3gKKd2x2A+tYZwwIB+PZ9PX4MO shiEjysMmiP7WtgJcxH51crEuK2BK9t811U3oAoWMuxpdBikSHrP2S/2qdZ6+z+Q2q1V no0dlIff0nSgSBymPX29Pel2LKLboGAdGikauce8sTfM9OST9vxXZa8dMNbYwp/wNQ0w HOP0QT9MtAuDzAlrJjuBY0ZGZL7m02u9G2cFuXgZumRRthK+jSlSLtnVgyN8v4nSKVeS Vt3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:ironport-sdr:ironport-sdr; bh=8IL4nRPO0E8ew1NY/VAL4At9WMEQtPxBK+gDESwd9Y4=; b=LT50x5uv6CN9e376G43u1KlQ6QL4VO6VDNNMibEQsKBLk5GWaoISkgUjXRlLFi5qd9 14I89326TjsqHeq9loZn22QRklHYcGj5XYJ503nqrMr1iEMKp+hQkzRuUcHxKbQYgoKu nF4SC2vNQ36OATCiYc4YkeLpAj+Io1Fd98mKqXqDcqIItArfzRWypVb1DVopIeFjbJM4 CPdpF/IraEd96Kg2YD/pQ2oePnZ5UYWl1V9AJe/uK6yUlahtODqeVIaPXiGiu9AWJkXe rUGACLNavA04MHIDDUmeMs2cCe0iAruq21Hutu4lg8m5IXoHivzaTRBw6pzUGBLkPsxW G0Sg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ly5si11748150ejb.500.2020.09.22.17.07.01; Tue, 22 Sep 2020 17:07:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726943AbgIVXoI (ORCPT + 99 others); Tue, 22 Sep 2020 19:44:08 -0400 Received: from mga12.intel.com ([192.55.52.136]:9371 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726641AbgIVXoH (ORCPT ); Tue, 22 Sep 2020 19:44:07 -0400 IronPort-SDR: zacx9vCvepX8c/Qp3UIQNTm0Ki6lB+r2ukYJ+KfkxYiWPOT/8lp1q+N+0qOTt9112NZvM8hNZa rfs3AeeMPX6w== X-IronPort-AV: E=McAfee;i="6000,8403,9752"; a="140214880" X-IronPort-AV: E=Sophos;i="5.77,292,1596524400"; d="scan'208";a="140214880" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 16:44:07 -0700 IronPort-SDR: 3vPIyamVPg+0BpPtKtRSoPSz9klirYJAZ1WffMml8Du0jj6/D4RBohrmbblGmjKJ2KQe6611sU JLayg4nKgq0A== X-IronPort-AV: E=Sophos;i="5.77,292,1596524400"; d="scan'208";a="486178382" Received: from nfoneill-mobl.amr.corp.intel.com (HELO [10.254.96.26]) ([10.254.96.26]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 16:44:07 -0700 Subject: Re: [PATCH v3 1/1] PCI/ERR: Fix reset logic in pcie_do_recovery() call To: Bjorn Helgaas Cc: bhelgaas@google.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, ashok.raj@intel.com, Jay Vosburgh References: <20200922233333.GA2239404@bjorn-Precision-5520> From: "Kuppuswamy, Sathyanarayanan" Message-ID: <704c39bf-6f0c-bba3-70b8-91de6a445e43@linux.intel.com> Date: Tue, 22 Sep 2020 16:44:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200922233333.GA2239404@bjorn-Precision-5520> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/22/20 4:33 PM, Bjorn Helgaas wrote: > On Tue, Sep 22, 2020 at 02:44:51PM -0700, Kuppuswamy, Sathyanarayanan wrote: >> >> >> On 9/22/20 11:52 AM, Bjorn Helgaas wrote: >>> On Fri, Jul 24, 2020 at 12:07:55PM -0700, sathyanarayanan.kuppuswamy@linux.intel.com wrote: >>>> From: Kuppuswamy Sathyanarayanan >>>> >>>> Current pcie_do_recovery() implementation has following two issues: >>>> >>> >>> I'm having trouble parsing this out, probably just lack of my >>> understanding... >>> >>>> 1. Fatal (DPC) error recovery is currently broken for non-hotplug >>>> capable devices. Current fatal error recovery implementation relies >>>> on PCIe hotplug (pciehp) handler for detaching and re-enumerating >>>> the affected devices/drivers. pciehp handler listens for DLLSC state >>>> changes and handles device/driver detachment on DLLSC_LINK_DOWN event >>>> and re-enumeration on DLLSC_LINK_UP event. So when dealing with >>>> non-hotplug capable devices, recovery code does not restore the state >>>> of the affected devices correctly. >>> >>> Apparently in the hotplug case, something *does* restore the state of >>> affected devices? >> >> Yes, in hotplug case, DLLSC state change handler takes over detachment >> /cleanup and re-attachment of affected devices/drivers. > > Where does the restore happen here? I.e., what function does this? DLLSC link down event will remove affected devices/drivers. And link up event will re-create all devices. on DLLSC link down event ->pciehp_ist() ->pciehp_handle_presence_or_link_change() ->pciehp_disable_slot() ->__pciehp_disable_slot() ->remove_board() ->pciehp_unconfigure_device() on DLLSC link up event ->pciehp_ist() ->pciehp_handle_presence_or_link_change() ->pciehp_enable_slot() ->__pciehp_enable_slot() ->board_added() ->pciehp_configure_device() > -- Sathyanarayanan Kuppuswamy Linux Kernel Developer