From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758800AbdCVGrE (ORCPT ); Wed, 22 Mar 2017 02:47:04 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:26816 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1758387AbdCVGqz (ORCPT ); Wed, 22 Mar 2017 02:46:55 -0400 X-IronPort-AV: E=Sophos;i="5.22,518,1449504000"; d="scan'208";a="16853642" Subject: Re: [PATCH] pci-error-recovery: doc cleanup To: References: <1490102658-22768-1-git-send-email-caoj.fnst@cn.fujitsu.com> CC: "linux-pci@vger.kernel.org" , , "linux-kernel@vger.kernel.org" , Bjorn Helgaas , Jonathan Corbet , "Michael S. Tsirkin" From: Cao jin Message-ID: <58D21FDF.4000506@cn.fujitsu.com> Date: Wed, 22 Mar 2017 14:55:27 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.226.69] X-yoursite-MailScanner-ID: 1711147EE1E1.A978D X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: caoj.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org CC MST who touched this file in last commit on it. On 03/22/2017 01:48 PM, Linas Vepstas wrote: > Hi, > > On Tue, Mar 21, 2017 at 9:24 PM, Cao jin wrote: >> Include whitespace shooting; correction; typo fix; superfluous word >> dropping. > >> >> diff --git a/Documentation/PCI/pci-error-recovery.txt b/Documentation/PCI/pci-error-recovery.txt >> index da3b217..0b6bb3e 100644 >> --- a/Documentation/PCI/pci-error-recovery.txt >> +++ b/Documentation/PCI/pci-error-recovery.txt >> >> @@ -231,14 +231,14 @@ proceeds to STEP 4 (Slot Reset) >> STEP 3: Link Reset >> ------------------ >> The platform resets the link. This is a PCI-Express specific step >> -and is done whenever a non-fatal error has been detected that can be >> +and is done whenever a fatal error has been detected that can be >> "solved" by resetting the link. > > First: I thought I saw a patch a few months ago that proposed removing > the link rest step. I don't know if the patch was accepted or not. > Yes, I sent this one and I asked to ignore it. At that time, .link_reset handler still exists, now is gone. > If link resets are still supported, then they can only fix NON-fatal errors: > basically, one resets the link, and only the link; one does NOT reset > either the device driver, nor the device state. The idea is that after a link > reset, communications with the device can immediately resume right > where it left off. (this can be hard in practice, if the driver/firmware doesn't > know what it was doing when the error occurred. this might be why no one > implements it.) Anyway, the whole point of a link reset is that it is > explicitly > a non-fatal error. > Perhaps you are still talking about link re-training. After last commit on this file, section "Link Reset" seems only focus on PCI-Express. If it is a PCI-Express specific step, then I think the "fatal" & "non-fatal" referred here are in the PCI-Express(AER) territory, and according to the AER driver(function do_recovery()), platform level link reset targeted to fatal error. -- Sincerely, Cao jin