Received: by 10.192.165.156 with SMTP id m28csp1388257imm; Wed, 11 Apr 2018 18:45:46 -0700 (PDT) X-Google-Smtp-Source: AIpwx48DT1JgwYQYx3+9yhPj+LYTCsaoOmqM5OUEgw+maGpXj9RosPYcEK4Wo0nFMedvU/INvtHy X-Received: by 2002:a17:902:a981:: with SMTP id bh1-v6mr7677412plb.255.1523497546579; Wed, 11 Apr 2018 18:45:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523497546; cv=none; d=google.com; s=arc-20160816; b=RhtU1VkffaoWWRLuxvpuc8HpK9DSeX+mCubFhgQAF8YNSyrEzeW0QqGw8uHTAg61h1 D5ktP7W1TvJXAK+5IgdpoMPKMcbWAaVau84NCjYMK+gRoYpWEq5fTARO3tiSWqJaD1Sv RpJ2BYO37gusyq+hs8bsWMV8yU8LaVDGl5VsePQE0XsPNB13RM6vwxDPjNSXC311k8TM mtJXkqpRfiiTPq6uq0XEo0NA53fc20SD9WpMe6VVRCXFcs+ovlz0Br5xgHN8fJlZWCS3 GX+UcXIRaKBqZ6gx+y/3jcOHWX2lRYyA+64GQF9mXwjUEm9cPPAfuls6mWeO77KDHCxm Ao4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=OAWu8zFPkO7ByLt31CKNVDhAcQ6m0g76C83HpCvjpuc=; b=0hGQS4/OYTZ8e3oD/c3gpi7+X1jPPj9v96NEc0xUBpkg35jl8OCprUFxKhvtxhgSYf DqWJ2fgqryFtXad6W6AccHWI+C8muCzdi5rYRIMw5fdMTgbVrXoDuqsLZPV08G0CSTge xVVZORY7m0BSQ3ztfLrq255udhMfK986MCcYtqyJaBuOBiGCLcMYbIT455O1F0TWedIy eF8p8TjExFUewPB7irtZZYSB952LxGM3L3JxpZv7VKCxgu07qoLDzO32UzMryVhuJXYk QaBsKkg51KX5ZK9CAI2DoovUCT0vFPGuDtBnEKpuQgVVYZRFTynnYoEP0ovDOoO14aSP 9Byw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=gsm5v70c; dkim=pass header.i=@codeaurora.org header.s=default header.b=cer+lou3; 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 a3-v6si2263495plc.740.2018.04.11.18.45.09; Wed, 11 Apr 2018 18:45:46 -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=gsm5v70c; dkim=pass header.i=@codeaurora.org header.s=default header.b=cer+lou3; 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 S1752646AbeDLBmC (ORCPT + 99 others); Wed, 11 Apr 2018 21:42:02 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:60326 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752003AbeDLBmA (ORCPT ); Wed, 11 Apr 2018 21:42:00 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 068E160F8D; Thu, 12 Apr 2018 01:41:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1523497320; bh=XuweS+E6bacMj4BLEV2PxhvLxyx+QC/Si+LwfI6/7JM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gsm5v70cPEMebpDv+DuhR+YF/1MpC+lX5ffdOX/kyPmRjong6HNDuVx/CTBXD6lJM 6oUoMCrZfezpSNEVcGh2/C9Czfv4+ZJ9EwLf8j26yv6zWqNe6qpiXz9A6Upm/2Ky96 kh1mhUBHiVSgmj6ATyzo3AXI4ehceHs0P5tsOJY4= 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 [192.168.0.105] (cpe-174-109-247-98.nc.res.rr.com [174.109.247.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 8B85360290; Thu, 12 Apr 2018 01:41:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1523497319; bh=XuweS+E6bacMj4BLEV2PxhvLxyx+QC/Si+LwfI6/7JM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cer+lou3mlKN8InpZwWFUPbzZAcyPChfB5LX12GaFQlHxJB2yQ8iMMzE+a7IQlGRk D73j6zysIVAF7SuIDTJP6erghnC20rijHV+S1LY8pUP2gyJEuN4BSWWGo2OPnJDyA3 3af4fcTKGDLWH6Db3wHlMIr9d6E2SQpXivcW8R20= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 8B85360290 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH v13 6/6] PCI/DPC: Do not do recovery for hotplug enabled system To: Bjorn Helgaas , Oza Pawandeep Cc: 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 , Timur Tabi References: <1523284914-2037-1-git-send-email-poza@codeaurora.org> <1523284914-2037-7-git-send-email-poza@codeaurora.org> <20180410210349.GG54986@bhelgaas-glaptop.roam.corp.google.com> From: Sinan Kaya Message-ID: <13efe2e8-74c8-acb4-ec58-f79b14a1f182@codeaurora.org> Date: Wed, 11 Apr 2018 21:41:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180410210349.GG54986@bhelgaas-glaptop.roam.corp.google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/10/2018 5:03 PM, Bjorn Helgaas wrote: >> DPC and AER should attempt recovery in the same way, except the >> cases where system is with hotplug enabled. > What's the connection with hotplug? I see from the patch that for > hotplug bridges you remove the tree below the bridge, and otherwise > you just reset the secondary link (I think). > > The changelog should explain why we need the difference. > > I'm a little skeptical to begin with, because I'm not sure why we > should handle a DPC event differently just because a bridge has the > *capability* of hotplug. Even if a hotplug bridge reports a DPC > event, that doesn't necessarily mean a hotplug has occurred. > Let's do a recap on what we have discussed about this until now. There are two conflicting error recovery mechanisms for PCIe. If a system supports both hotplug and DPC, endpoint can be removed and inserted safely. DPC driver shuts down the driver on link down. When link comes back up, hotplug driver takes over and initiates an enumeration process. Keith mentioned the stop and re-enumerate design was chosen because someone could remove a drive and insert an unrelated drive back to the system. We can't really save and restore state as we do in the AER path. Now, let's assume a system without hotplug capability. Second mechanism is to go through DPC/AER path and do an automatic link down recovery via DPC retrain/secondary bus reset including register save and restore. Second mechanism is more suitable for handling "surprise link down" event. The goal is to retrain the link and continue driver operation. The goal of this patch to separate these two cases from each other as the DPC driver needs to work on both contexts. Current DPC code doesn't handle the second use case. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.