linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] PCI: Reduce delay after FLR of Microsoft MANA devices
@ 2025-05-28 18:10 grwhyte
  2025-05-29 10:34 ` Lukas Wunner
  0 siblings, 1 reply; 4+ messages in thread
From: grwhyte @ 2025-05-28 18:10 UTC (permalink / raw)
  To: linux-pci; +Cc: shyamsaini, code, Okaya, bhelgaas, linux-kernel

From: Graham Whyte <grwhyte@linux.microsoft.com>

Add a device-specific reset for Microsoft MANA devices with the FLR
delay reduced from 100ms to 10ms. While this is not compliant with the pci
spec, these devices safely complete the FLR much quicker than 100ms and
this can be reduced to optimize certain scenarios

Signed-off-by: Graham Whyte <grwhyte@linux.microsoft.com>

---
Changes in v2:
- Removed unnecessary EXPORT_SYMBOL_GPL for function pci_dev_wait
- Link to v1:https://lore.kernel.org/linux-pci/20250522085253.GN7435@unreal/T/#m7453647902a1b22840f5e39434a631fd7b2515ce
---
 drivers/pci/pci.c    |  2 +-
 drivers/pci/pci.h    |  1 +
 drivers/pci/quirks.c | 55 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 9cb1de7658b5..28f3bfd24357 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1262,7 +1262,7 @@ void pci_resume_bus(struct pci_bus *bus)
 		pci_walk_bus(bus, pci_resume_one, NULL);
 }
 
-static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
+int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
 {
 	int delay = 1;
 	bool retrain = false;
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f2958318d259..3a98e00eb02a 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -109,6 +109,7 @@ void pci_init_reset_methods(struct pci_dev *dev);
 int pci_bridge_secondary_bus_reset(struct pci_dev *dev);
 int pci_bus_error_reset(struct pci_dev *dev);
 int __pci_reset_bus(struct pci_bus *bus);
+int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout);
 
 struct pci_cap_saved_data {
 	u16		cap_nr;
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index c354276d4bac..94bd2c82cbbd 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4205,6 +4205,55 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
 	return 0;
 }
 
+#define MSFT_PCIE_RESET_READY_POLL_MS 60000 /* msec */
+#define MICROSOFT_2051_SVC 0xb210
+#define MICROSOFT_2051_MANA_MGMT 0x00b8
+#define MICROSOFT_2051_MANA_MGMT_GFT 0xb290
+
+/* Device specific reset for msft GFT and gdma devices */
+static int msft_pcie_flr(struct pci_dev *dev)
+{
+	if (!pci_wait_for_pending_transaction(dev))
+		pci_err(dev, "timed out waiting for pending transaction; "
+			"performing function level reset anyway\n");
+
+	pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR);
+
+	if (dev->imm_ready)
+		return 0;
+
+	/*
+	 * Per PCIe r4.0, sec 6.6.2, a device must complete an FLR within
+	 * 100ms, but may silently discard requests while the FLR is in
+	 * progress. However, 100ms is much longer than required for modern
+	 * devices, so we can afford to reduce the timeout to 10ms.
+	 */
+	usleep_range(10000, 10001);
+
+	return pci_dev_wait(dev, "FLR", MSFT_PCIE_RESET_READY_POLL_MS);
+}
+
+/*
+ * msft_pcie_reset_flr - initiate a PCIe function level reset
+ * @dev: device to reset
+ * @probe: if true, return 0 if device can be reset this way
+ *
+ * Initiate a function level reset on @dev.
+ */
+static int msft_pcie_reset_flr(struct pci_dev *dev, bool probe)
+{
+	if (dev->dev_flags & PCI_DEV_FLAGS_NO_FLR_RESET)
+		return -ENOTTY;
+
+	if (!(dev->devcap & PCI_EXP_DEVCAP_FLR))
+		return -ENOTTY;
+
+	if (probe)
+		return 0;
+
+	return msft_pcie_flr(dev);
+}
+
 static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
 		 reset_intel_82599_sfp_virtfn },
@@ -4220,6 +4269,12 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 		reset_chelsio_generic_dev },
 	{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
 		reset_hinic_vf_dev },
+	{ PCI_VENDOR_ID_MICROSOFT, MICROSOFT_2051_SVC,
+		msft_pcie_reset_flr},
+	{ PCI_VENDOR_ID_MICROSOFT, MICROSOFT_2051_MANA_MGMT,
+		msft_pcie_reset_flr},
+	{ PCI_VENDOR_ID_MICROSOFT, MICROSOFT_2051_MANA_MGMT_GFT,
+		msft_pcie_reset_flr},
 	{ 0 }
 };
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] PCI: Reduce delay after FLR of Microsoft MANA devices
  2025-05-28 18:10 [PATCH v2] PCI: Reduce delay after FLR of Microsoft MANA devices grwhyte
@ 2025-05-29 10:34 ` Lukas Wunner
  2025-05-30 16:26   ` Graham Whyte
  0 siblings, 1 reply; 4+ messages in thread
From: Lukas Wunner @ 2025-05-29 10:34 UTC (permalink / raw)
  To: grwhyte; +Cc: linux-pci, shyamsaini, code, Okaya, bhelgaas, linux-kernel

On Wed, May 28, 2025 at 06:10:47PM +0000, grwhyte@linux.microsoft.com wrote:
> Add a device-specific reset for Microsoft MANA devices with the FLR
> delay reduced from 100ms to 10ms. While this is not compliant with the pci
> spec, these devices safely complete the FLR much quicker than 100ms and
> this can be reduced to optimize certain scenarios

How often do you reset these devices that 90 msec makes a difference?
What are these "certain scenarios"?

There are already "d3hot_delay" and "d3cold_delay" members in
struct pci_dev.  I'm wondering if it would make sense to add
another one, say, "flr_delay".  That would allow other devices
to reduce or lengthen the delay without each of them having to
duplicate pcie_flr().  The code duplication makes this difficult
to maintain long-term.

Thanks,

Lukas

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] PCI: Reduce delay after FLR of Microsoft MANA devices
  2025-05-29 10:34 ` Lukas Wunner
@ 2025-05-30 16:26   ` Graham Whyte
  2025-05-31 14:09     ` Lukas Wunner
  0 siblings, 1 reply; 4+ messages in thread
From: Graham Whyte @ 2025-05-30 16:26 UTC (permalink / raw)
  To: Lukas Wunner; +Cc: linux-pci, shyamsaini, code, Okaya, bhelgaas, linux-kernel



On 5/29/2025 3:34 AM, Lukas Wunner wrote:
> On Wed, May 28, 2025 at 06:10:47PM +0000, grwhyte@linux.microsoft.com wrote:
>> Add a device-specific reset for Microsoft MANA devices with the FLR
>> delay reduced from 100ms to 10ms. While this is not compliant with the pci
>> spec, these devices safely complete the FLR much quicker than 100ms and
>> this can be reduced to optimize certain scenarios
> 
> How often do you reset these devices that 90 msec makes a difference?
> What are these "certain scenarios"?
> 
VF removal and rescan is the main scenario for runtime repairs and driver updates.
Doing this on scale with 100ms adds up to significant time across multiple VFs.

> There are already "d3hot_delay" and "d3cold_delay" members in
> struct pci_dev.  I'm wondering if it would make sense to add
> another one, say, "flr_delay".  That would allow other devices
> to reduce or lengthen the delay without each of them having to
> duplicate pcie_flr().  The code duplication makes this difficult
> to maintain long-term.
> 
This is a good suggestion, we can make this more generic.

> Thanks,
> 
> Lukas


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] PCI: Reduce delay after FLR of Microsoft MANA devices
  2025-05-30 16:26   ` Graham Whyte
@ 2025-05-31 14:09     ` Lukas Wunner
  0 siblings, 0 replies; 4+ messages in thread
From: Lukas Wunner @ 2025-05-31 14:09 UTC (permalink / raw)
  To: Graham Whyte; +Cc: linux-pci, shyamsaini, code, Okaya, bhelgaas, linux-kernel

On Fri, May 30, 2025 at 09:26:16AM -0700, Graham Whyte wrote:
> On 5/29/2025 3:34 AM, Lukas Wunner wrote:
> > On Wed, May 28, 2025 at 06:10:47PM +0000, grwhyte@linux.microsoft.com wrote:
> > > Add a device-specific reset for Microsoft MANA devices with the FLR
> > > delay reduced from 100ms to 10ms. While this is not compliant with the
> > > pci spec, these devices safely complete the FLR much quicker than 100ms
> > > and this can be reduced to optimize certain scenarios
> > 
> > How often do you reset these devices that 90 msec makes a difference?
> > What are these "certain scenarios"?
> 
> VF removal and rescan is the main scenario for runtime repairs and driver
> updates.
> Doing this on scale with 100ms adds up to significant time across multiple
> VFs.

Please mention this in the commit message to avoid head-scratching
by someone reading it down the road.

Thanks,

Lukas

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-05-31 14:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-05-28 18:10 [PATCH v2] PCI: Reduce delay after FLR of Microsoft MANA devices grwhyte
2025-05-29 10:34 ` Lukas Wunner
2025-05-30 16:26   ` Graham Whyte
2025-05-31 14:09     ` Lukas Wunner

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).