From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: grwhyte@linux.microsoft.com
Cc: linux-pci@vger.kernel.org, shyamsaini@linux.microsoft.com,
code@tyhicks.com, Okaya@kernel.org, bhelgaas@google.com,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] PCI: Reduce FLR delay to 10ms for MSFT devices
Date: Fri, 13 Jun 2025 13:31:27 +0300 (EEST) [thread overview]
Message-ID: <eb9199fa-1a2a-910c-35f8-ea316a57c55d@linux.intel.com> (raw)
In-Reply-To: <20250611000552.1989795-3-grwhyte@linux.microsoft.com>
On Wed, 11 Jun 2025, grwhyte@linux.microsoft.com wrote:
> From: Graham Whyte <grwhyte@linux.microsoft.com>
>
> Add a new quirk to reduce the delay after a FLR to 10ms
> for MSFT devices. These devices complete the FLR well within the default
> 100ms timeframe and this path can be optimized for VF removal during
What is "this path" in this context? Try to avoid vague references like
that.
> runtime repairs and driver updates. These devices do not support immediate
> readiness or readiness time reporting
When talking about something that relates to PCIe spec, please also refer
to PCIe spec and use the terminology matching to the spec (+ capitalization).
Missing .
Please also reflow the paragraph as the first line is clearly not full.
This probably belongs more to the previous patch changelog than this one,
as the justification: I suggest you start by stating the problem. So state
the spec defined wait (+ spec reference), and why that is problem. Then
explain the solution in another paragraph.
> Signed-off-by: Graham Whyte <grwhyte@linux.microsoft.com>
> ---
> drivers/pci/quirks.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index d7f4ee634263..d704606330bd 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -6335,3 +6335,23 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
> #endif
> +
> +#define MICROSOFT_2051_SVC 0xb210
> +#define MICROSOFT_2051_MANA_MGMT 0x00b8
> +#define MICROSOFT_2051_MANA_MGMT_GFT 0xb290
> +
> +/*
> + * For devices that don't require the full 100ms sleep
> + * after FLR and do not support immediate readiness or readiness
> + * time reporting
> + */
> +static void pci_fixup_pci_flr_10msec(struct pci_dev *pdev)
> +{
> + pdev->flr_delay = 10000;
10 * USEC_PER_MSEC
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_MICROSOFT, MICROSOFT_2051_SVC,
> + pci_fixup_pci_flr_10msec);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_MICROSOFT, MICROSOFT_2051_MANA_MGMT,
> + pci_fixup_pci_flr_10msec);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_MICROSOFT, MICROSOFT_2051_MANA_MGMT_GFT,
> + pci_fixup_pci_flr_10msec);
>
--
i.
next prev parent reply other threads:[~2025-06-13 10:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-11 0:05 [PATCH v3 0/2] PCI: Reduce FLR delay to 10ms for MSFT devices grwhyte
2025-06-11 0:05 ` [PATCH v3 1/2] PCI: Add flr_delay parameter to pci_dev struct grwhyte
2025-06-13 10:23 ` Ilpo Järvinen
2025-08-06 22:06 ` Bjorn Helgaas
2025-06-11 0:05 ` [PATCH v3 2/2] PCI: Reduce FLR delay to 10ms for MSFT devices grwhyte
2025-06-13 10:31 ` Ilpo Järvinen [this message]
2025-06-11 3:27 ` [PATCH v3 0/2] " Christoph Hellwig
2025-06-11 7:23 ` Niklas Cassel
2025-06-11 20:08 ` Graham Whyte
2025-06-12 6:31 ` Christoph Hellwig
2025-06-12 16:41 ` Graham Whyte
2025-06-13 15:33 ` Bjorn Helgaas
2025-06-16 19:02 ` Graham Whyte
2025-06-16 21:05 ` Bjorn Helgaas
2025-06-18 16:42 ` Graham Whyte
2025-07-02 17:03 ` Graham Whyte
2025-06-13 11:42 ` Manivannan Sadhasivam
2025-06-13 13:45 ` Lukas Wunner
2025-06-13 13:56 ` Manivannan Sadhasivam
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=eb9199fa-1a2a-910c-35f8-ea316a57c55d@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=Okaya@kernel.org \
--cc=bhelgaas@google.com \
--cc=code@tyhicks.com \
--cc=grwhyte@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=shyamsaini@linux.microsoft.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.