linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
To: <linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
	Lukas Wunner <lukas@wunner.de>,
	"Kuppuswamy Sathyanarayanan" 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Yazen Ghannam <yazen.ghannam@amd.com>,
	Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Subject: [PATCH v4 3/3] PCI: pciehp: Clear AtomicOps unconditionally on hot remove.
Date: Tue, 15 Aug 2023 21:20:43 +0000	[thread overview]
Message-ID: <20230815212043.114913-4-Smita.KoralahalliChannabasappa@amd.com> (raw)
In-Reply-To: <20230815212043.114913-1-Smita.KoralahalliChannabasappa@amd.com>

On a hot-plug, the optional capabilities ARI Forwarding Enable, AtomicOp
Requester Enable and 10-Bit Tag Requester Enable in DEVCTL2 must be
re-negotiated between endpoint and root port for optimal operation.

PCIe r6.0 sec 6.13 and 6.15 [1], points out that following a hot-plug
event, clear the ARI Forwarding Enable bit and AtomicOp Requester Enable
as its not determined whether the next device inserted will support these
capabilities. AtomicOp capabilities are not supported on PCI Express to
PCI/PCI-X Bridges and any newly added component may not be an ARI device.

The enablement and disablement of ARI Forwarding Enable and 10-bit Tag
Requester Enable is already been taken care in pci_configure_ari() and
pci_configure_ten_bit_tag() respectively.

AtomicOp requests are not enabled indiscriminately by PCI core as there
could be devices where AtomicOps are nominally supported but untested or
broken. Additionally, there is no explicit capability bit to determine
the support for AtomicOps Requester.

Moreover, it is difficult to determine if the AtomicOps are enabled by
reading the "AtomicOp Requester Enable" Device Control 2 register as
the PCIe r6.0 sec 7.5.3.16 [1], states "AtomicOps Requester Enable is
permitted to be RW even if no AtomicOp Requester capabilities are
supported by the Endpoint or Root Port", thereby substantiating devices
that hardwires this bit to '1' is also valid. Hence, clear AtomicOp
Requester Enable unconditionally on hot remove.

[1] PCI Express Base Specification Revision 6.0, Dec 16 2021.
    https://members.pcisig.com/wg/PCI-SIG/document/16609

Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
---
v2:
	Clear all optional capabilities in Device Control 2 register
	instead of individually clearing ARI Forwarding Enable,
	AtomicOp Requestor Enable and 10-bit Tag Requestor Enable.
v3:
	Restore clearing only ARI, Atomic Op and 10 bit tags as these are
	the optional capabilities.
	Provide all necessary information in commit description.
	Clear register bits of the hotplug port.
v4:
	Cleared only AtomicOps instead of all three bits.
	Removed brackets.
	Moved clearing at the end after pci_unlock_rescan_remove().
---
 drivers/pci/hotplug/pciehp_pci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c
index ad12515a4a12..a3adbe89239c 100644
--- a/drivers/pci/hotplug/pciehp_pci.c
+++ b/drivers/pci/hotplug/pciehp_pci.c
@@ -134,4 +134,7 @@ void pciehp_unconfigure_device(struct controller *ctrl, bool presence)
 	}
 
 	pci_unlock_rescan_remove();
+
+	pcie_capability_clear_word(ctrl->pcie->port, PCI_EXP_DEVCTL2,
+				   PCI_EXP_DEVCTL2_ATOMIC_REQ);
 }
-- 
2.17.1


      parent reply	other threads:[~2023-08-15 21:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-15 21:20 [PATCH v4 0/3] PCI: pciehp: Add support for native AER and DPC handling on async remove Smita Koralahalli
2023-08-15 21:20 ` [PATCH v4 1/3] PCI: pciehp: Add support for async hotplug with native AER and DPC/EDR Smita Koralahalli
2023-08-28  7:35   ` Lukas Wunner
2023-09-12 22:45     ` Smita Koralahalli
2023-09-13  4:07       ` Lukas Wunner
2023-08-15 21:20 ` [PATCH v4 2/3] PCI: Enable support for 10-bit Tag during device enumeration Smita Koralahalli
2023-08-28  9:54   ` Lukas Wunner
2023-09-12 22:39     ` Smita Koralahalli
2023-08-15 21:20 ` Smita Koralahalli [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=20230815212043.114913-4-Smita.KoralahalliChannabasappa@amd.com \
    --to=smita.koralahallichannabasappa@amd.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mahesh@linux.ibm.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=yazen.ghannam@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).