From: Lukas Wunner <lukas@wunner.de>
To: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Riana Tauro <riana.tauro@intel.com>,
Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com>,
"Sean C. Dardis" <sean.c.dardis@intel.com>,
Terry Bowman <terry.bowman@amd.com>,
Niklas Schnelle <schnelle@linux.ibm.com>,
Linas Vepstas <linasvepstas@gmail.com>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Oliver OHalloran <oohall@gmail.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH 1/5] PCI/AER: Allow drivers to opt in to Bus Reset on Non-Fatal Errors
Date: Sun, 17 Aug 2025 15:45:25 +0200 [thread overview]
Message-ID: <aKHc9RxYHC0CpbeS@wunner.de> (raw)
In-Reply-To: <cd952c82-9f8b-4396-9170-b34d539a8fac@linux.intel.com>
On Wed, Aug 13, 2025 at 04:01:09PM -0700, Sathyanarayanan Kuppuswamy wrote:
> On 8/12/25 10:11 PM, Lukas Wunner wrote:
> > The file Documentation/PCI/pcieaer-howto.rst hints at a rationale for
> > always performing a Bus Reset on Fatal Errors: "Fatal errors [...] cause
> > the link to be unreliable. [...] This [reset_link] callback is used to
> > reset the PCIe physical link when a fatal error happens. If an error
> > message indicates a fatal error, [...] performing link reset at upstream
> > is necessary."
>
> In the code we don't seem to differentiate link_reset and slot_reset. But
> the Documentation calls them into two steps. Do you think we should
> fix the Documentation?
reset_link and slot_reset are two different things:
* slot_reset is the ->slot_reset() callback in struct pci_error_handlers.
* reset_link is the reset_subordinates() callback passed in to
pcie_do_recovery().
Commit 8f1bbfbc3596 renamed reset_link() to reset_subordinates() but
neglected to update Documentation/PCI/pcieaer-howto.rst.
Commit b6cf1a42f916 dropped the reset_link() callback from struct
pcie_port_service_driver and dropped default_reset_link() in favor
of passing aer_root_reset() to pcie_do_recovery(). Yet the documentation
continues referring to a "default reset_link callback" and incorrectly
claims that "Upstream Port drivers may provide their own reset_link
functions".
I've begun updating the documentation and intend to submit that separately.
Thanks,
Lukas
next prev parent reply other threads:[~2025-08-17 13:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 5:11 [PATCH 0/5] PCI: Reduce AER / EEH deviations Lukas Wunner
2025-08-13 5:11 ` Lukas Wunner
2025-08-13 5:11 ` [PATCH 1/5] PCI/AER: Allow drivers to opt in to Bus Reset on Non-Fatal Errors Lukas Wunner
2025-08-13 23:01 ` Sathyanarayanan Kuppuswamy
2025-08-17 13:45 ` Lukas Wunner [this message]
2025-08-14 7:56 ` Niklas Schnelle
2025-08-14 9:36 ` Lukas Wunner
2025-08-14 19:29 ` Sathyanarayanan Kuppuswamy
2025-08-17 13:17 ` Lukas Wunner
2025-08-17 16:10 ` Sathyanarayanan Kuppuswamy
2025-08-14 20:31 ` Niklas Schnelle
2025-08-18 23:17 ` Linas Vepstas
2025-08-17 16:11 ` Sathyanarayanan Kuppuswamy
2025-08-13 5:11 ` [PATCH 2/5] PCI/ERR: Fix uevent on failure to recover Lukas Wunner
2025-08-13 23:01 ` Sathyanarayanan Kuppuswamy
2025-08-14 7:08 ` Niklas Schnelle
2025-08-13 5:11 ` [PATCH 3/5] PCI/ERR: Notify drivers " Lukas Wunner
2025-08-13 23:05 ` Sathyanarayanan Kuppuswamy
2025-08-13 5:11 ` [PATCH 4/5] PCI/ERR: Update device error_state already after reset Lukas Wunner
2025-08-13 23:43 ` Sathyanarayanan Kuppuswamy
2025-08-13 5:11 ` [PATCH 5/5] PCI/ERR: Remove remnants of .link_reset() callback Lukas Wunner
2025-08-14 0:40 ` Sathyanarayanan Kuppuswamy
2025-08-13 18:21 ` [PATCH 0/5] PCI: Reduce AER / EEH deviations Bjorn Helgaas
2025-08-14 0:30 ` Linas Vepstas
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=aKHc9RxYHC0CpbeS@wunner.de \
--to=lukas@wunner.de \
--cc=aravind.iddamsetty@linux.intel.com \
--cc=helgaas@kernel.org \
--cc=linasvepstas@gmail.com \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mahesh@linux.ibm.com \
--cc=manivannan.sadhasivam@oss.qualcomm.com \
--cc=oohall@gmail.com \
--cc=riana.tauro@intel.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=schnelle@linux.ibm.com \
--cc=sean.c.dardis@intel.com \
--cc=terry.bowman@amd.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.