All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wesley Sheng <wesley.sheng@amd.com>
To: linasvepstas@gmail.com, ruscur@russell.cc, oohall@gmail.com,
	bhelgaas@google.com, corbet@lwn.net, linux-pci@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: wesleyshenggit@sina.com
Subject: Re: [PATCH] Documentation: PCI: pci-error-recovery: rearrange the general sequence
Date: Fri, 2 Jul 2021 10:41:23 +0800	[thread overview]
Message-ID: <20210702024123.GA2714@buildhost> (raw)
In-Reply-To: <20210701222231.GA102933@bjorn-Precision-5520>

On Thu, Jul 01, 2021 at 05:22:31PM -0500, Bjorn Helgaas wrote:
> Please make the subject a little more specific.  "rearrange the
> general sequence" doesn't say anything about what was affected.
> 
> On Fri, Jun 18, 2021 at 02:04:46PM +0800, Wesley Sheng wrote:
> > Reset_link() callback function was called before mmio_enabled() in
> > pcie_do_recovery() function actually, so rearrange the general
> > sequence betwen step 2 and step 3 accordingly.
> 
> s/betwen/between/
> 
> Not sure "general" adds anything in this sentence.  "Step 2 and step
> 3" are not meaningful here in the commit log.  It needs to spell out
> what those steps are so the log makes sense by itself.
> 
> "reset_link" does not appear in pcie_do_recovery().  I'm guessing
> you're referring to the "reset_subordinates" function pointer?
>
Yes, you are right.
pcieaer-howto.rst has a section named with "Provide callbacks",
the callback supplied to pcie_do_recovery() was referred to 
reset_link.
 
> > Signed-off-by: Wesley Sheng <wesley.sheng@amd.com>
> 
> I didn't quite understand your response to Oliver, so I'll wait for
> your corrections and his ack before proceeding.
>
OK.
I thought step 2 MMIO Enabled and step 3 link reset should swap sequence.

> > ---
> >  Documentation/PCI/pci-error-recovery.rst | 23 ++++++++++++-----------
> >  1 file changed, 12 insertions(+), 11 deletions(-)
> > 
> > diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
> > index 187f43a03200..ac6a8729ef28 100644
> > --- a/Documentation/PCI/pci-error-recovery.rst
> > +++ b/Documentation/PCI/pci-error-recovery.rst
> > @@ -184,7 +184,14 @@ is STEP 6 (Permanent Failure).
> >     and prints an error to syslog.  A reboot is then required to
> >     get the device working again.
> >  
> > -STEP 2: MMIO Enabled
> > +STEP 2: Link Reset
> > +------------------
> > +The platform resets the link.  This is a PCI-Express specific step
> > +and is done whenever a fatal error has been detected that can be
> > +"solved" by resetting the link.
> > +
> > +
> > +STEP 3: MMIO Enabled
> >  --------------------
> >  The platform re-enables MMIO to the device (but typically not the
> >  DMA), and then calls the mmio_enabled() callback on all affected
> > @@ -197,8 +204,8 @@ information, if any, and eventually do things like trigger a device local
> >  reset or some such, but not restart operations. This callback is made if
> >  all drivers on a segment agree that they can try to recover and if no automatic
> >  link reset was performed by the HW. If the platform can't just re-enable IOs
> > -without a slot reset or a link reset, it will not call this callback, and
> > -instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
> > +without a slot reset, it will not call this callback, and
> > +instead will have gone directly or STEP 4 (Slot Reset)
> 
> s/or/to/  ?
> 
> >  .. note::
> >  
> > @@ -210,7 +217,7 @@ instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
> >     such an error might cause IOs to be re-blocked for the whole
> >     segment, and thus invalidate the recovery that other devices
> >     on the same segment might have done, forcing the whole segment
> > -   into one of the next states, that is, link reset or slot reset.
> > +   into next states, that is, slot reset.
> 
> s/into next states/into the next state/ ?
> 
> >  The driver should return one of the following result codes:
> >    - PCI_ERS_RESULT_RECOVERED
> > @@ -233,17 +240,11 @@ The driver should return one of the following result codes:
> >  
> >  The next step taken depends on the results returned by the drivers.
> >  If all drivers returned PCI_ERS_RESULT_RECOVERED, then the platform
> > -proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations).
> > +proceeds to STEP 5 (Resume Operations).
> >  
> >  If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform
> >  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 fatal error has been detected that can be
> > -"solved" by resetting the link.
> > -
> >  STEP 4: Slot Reset
> >  ------------------
> >  
> > -- 
> > 2.25.1
> > 

      reply	other threads:[~2021-07-02  2:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-18  6:04 [PATCH] Documentation: PCI: pci-error-recovery: rearrange the general sequence Wesley Sheng
2021-06-18  6:04 ` Wesley Sheng
2021-06-18  7:21 ` Oliver O'Halloran
2021-06-18  7:21   ` Oliver O'Halloran
2021-06-29  3:34   ` Wesley Sheng
2021-06-29  3:34     ` Wesley Sheng
2021-07-01 22:22 ` Bjorn Helgaas
2021-07-01 22:22   ` Bjorn Helgaas
2021-07-02  2:41   ` Wesley Sheng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210702024123.GA2714@buildhost \
    --to=wesley.sheng@amd.com \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=linasvepstas@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=oohall@gmail.com \
    --cc=ruscur@russell.cc \
    --cc=wesleyshenggit@sina.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.