All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Lukas Wunner <lukas@wunner.de>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>
Cc: Terry Bowman <terry.bowman@amd.com>,
	Ilpo Jarvinen	 <ilpo.jarvinen@linux.intel.com>,
	Sathyanarayanan Kuppuswamy	
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Linas Vepstas	 <linasvepstas@gmail.com>,
	Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
	Oliver OHalloran <oohall@gmail.com>,
	linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
	linux-doc@vger.kernel.org,
	Brian Norris <briannorris@chromium.org>
Subject: Re: [PATCH v2 4/4] Documentation: PCI: Tidy error recovery doc's PCIe nomenclature
Date: Mon, 15 Sep 2025 17:46:53 +0200	[thread overview]
Message-ID: <4fa71778403c8025a85f30dd8a7dcf5bc9a4eaf9.camel@linux.ibm.com> (raw)
In-Reply-To: <db56b7ef12043f709a04ce67c1d1e102ab5f4e19.1757942121.git.lukas@wunner.de>

On Mon, 2025-09-15 at 15:50 +0200, Lukas Wunner wrote:
> Commit 11502feab423 ("Documentation: PCI: Tidy AER documentation")
> replaced the terms "PCI-E", "PCI-Express" and "PCI Express" with "PCIe"
> in the AER documentation.
> 
> Do the same in the documentation on PCI error recovery.  While at it,
> add a missing period and a missing blank.
> 
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> ---
>  Documentation/PCI/pci-error-recovery.rst | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
> index 9e1e2f2a13fa..5df481ac6193 100644
> --- a/Documentation/PCI/pci-error-recovery.rst
> +++ b/Documentation/PCI/pci-error-recovery.rst
> @@ -13,7 +13,7 @@ PCI Error Recovery
>  Many PCI bus controllers are able to detect a variety of hardware
>  PCI errors on the bus, such as parity errors on the data and address
>  buses, as well as SERR and PERR errors.  Some of the more advanced
> -chipsets are able to deal with these errors; these include PCI-E chipsets,
> +chipsets are able to deal with these errors; these include PCIe chipsets,
>  and the PCI-host bridges found on IBM Power4, Power5 and Power6-based
>  pSeries boxes. A typical action taken is to disconnect the affected device,
>  halting all I/O to it.  The goal of a disconnection is to avoid system
> @@ -206,7 +206,7 @@ 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)
> +instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset).
>  
>  .. note::
>  
> @@ -259,14 +259,14 @@ 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 either STEP 3 (Link Reset) or 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
> +The platform resets the link.  This is a PCIe specific step
>  and is done whenever a fatal error has been detected that can be
>  "solved" by resetting the link.
>  
> @@ -288,13 +288,13 @@ that is equivalent to what it would be after a fresh system
>  power-on followed by power-on BIOS/system firmware initialization.
>  Soft reset is also known as hot-reset.
>  
> -Powerpc fundamental reset is supported by PCI Express cards only
> +Powerpc fundamental reset is supported by PCIe cards only
>  and results in device's state machines, hardware logic, port states and
>  configuration registers to initialize to their default conditions.
>  
>  For most PCI devices, a soft reset will be sufficient for recovery.
>  Optional fundamental reset is provided to support a limited number
> -of PCI Express devices for which a soft reset is not sufficient
> +of PCIe devices for which a soft reset is not sufficient
>  for recovery.
>  
>  If the platform supports PCI hotplug, then the reset might be
> @@ -338,7 +338,7 @@ Result codes:
>  	- PCI_ERS_RESULT_DISCONNECT
>  	  Same as above.
>  
> -Drivers for PCI Express cards that require a fundamental reset must
> +Drivers for PCIe cards that require a fundamental reset must
>  set the needs_freset bit in the pci_dev structure in their probe function.
>  For example, the QLogic qla2xxx driver sets the needs_freset bit for certain
>  PCI card types::

Thanks for the bringing this in sync.

Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>

  reply	other threads:[~2025-09-15 15:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-15 13:50 [PATCH v2 0/4] Documentation: PCI: Update error recovery docs Lukas Wunner
2025-09-15 13:50 ` [PATCH v2 1/4] Documentation: PCI: Sync AER doc with code Lukas Wunner
2025-09-15 13:50 ` [PATCH v2 2/4] Documentation: PCI: Sync error recovery " Lukas Wunner
2025-09-15 15:51   ` Niklas Schnelle
2025-09-15 13:50 ` [PATCH v2 3/4] Documentation: PCI: Amend error recovery doc with DPC/AER specifics Lukas Wunner
2025-09-15 15:43   ` Niklas Schnelle
2025-09-15 13:50 ` [PATCH v2 4/4] Documentation: PCI: Tidy error recovery doc's PCIe nomenclature Lukas Wunner
2025-09-15 15:46   ` Niklas Schnelle [this message]
2025-09-15 15:25 ` [PATCH v2 0/4] Documentation: PCI: Update error recovery docs Sathyanarayanan Kuppuswamy
2025-09-16 15:55 ` Bjorn Helgaas

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=4fa71778403c8025a85f30dd8a7dcf5bc9a4eaf9.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=briannorris@chromium.org \
    --cc=corbet@lwn.net \
    --cc=helgaas@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linasvepstas@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lukas@wunner.de \
    --cc=mahesh@linux.ibm.com \
    --cc=oohall@gmail.com \
    --cc=sathyanarayanan.kuppuswamy@linux.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.