From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F980C0044D for ; Wed, 11 Mar 2020 23:10:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 35EA42074B for ; Wed, 11 Mar 2020 23:10:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731168AbgCKXKZ (ORCPT ); Wed, 11 Mar 2020 19:10:25 -0400 Received: from mga12.intel.com ([192.55.52.136]:12133 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729739AbgCKXKZ (ORCPT ); Wed, 11 Mar 2020 19:10:25 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2020 16:10:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,542,1574150400"; d="scan'208";a="322286118" Received: from linux.intel.com ([10.54.29.200]) by orsmga001.jf.intel.com with ESMTP; 11 Mar 2020 16:10:24 -0700 Received: from [10.7.201.16] (skuppusw-desk.jf.intel.com [10.7.201.16]) by linux.intel.com (Postfix) with ESMTP id 3ADED58033E; Wed, 11 Mar 2020 16:10:24 -0700 (PDT) Reply-To: sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH v17 09/12] PCI/AER: Allow clearing Error Status Register in FF mode To: Bjorn Helgaas Cc: Austin.Bolen@dell.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, ashok.raj@intel.com References: <20200311222352.GA200510@google.com> From: Kuppuswamy Sathyanarayanan Organization: Intel Message-ID: Date: Wed, 11 Mar 2020 16:07:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200311222352.GA200510@google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Hi Bjorn, Re-sending the response in text mode. On 3/11/20 3:23 PM, Bjorn Helgaas wrote: > Is any synchronization needed here between the EDR path and the > hotplug/enumeration path? If we want to follow the implementation note step by step (in sequence) then we need some synchronization between EDR path and enumeration path. But if its OK the achieve the same end result by following steps out of sequence then we don't need to create any dependency between EDR and enumeration paths. Currently we follow the later approach. For example, consider the case in flow chart where after sending success _OST, firmware decides to stop the recovery of the device. if we follow the flow chart as its then the steps should be, 1. clear the DPC status trigger 2. Send success code via _OST, and wait for return from _OST 3. if successful return then enumerate the child devices and reassign bus numbers. In current approach the steps followed are, 1. Clear the DPC status trigger. 2. Send success code via _OST 2. In parallel, LINK UP event path will enumerate the child devices. 3. if firmware decides not to recover the device,  then LINK DOWN event will eventually     remove them again. -- Sathyanarayanan Kuppuswamy Linux kernel developer