From: Bjorn Helgaas <helgaas@kernel.org>
To: Graham Whyte <grwhyte@linux.microsoft.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Niklas Cassel <cassel@kernel.org>,
linux-pci@vger.kernel.org, shyamsaini@linux.microsoft.com,
code@tyhicks.com, Okaya@kernel.org, bhelgaas@google.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/2] PCI: Reduce FLR delay to 10ms for MSFT devices
Date: Fri, 13 Jun 2025 10:33:04 -0500 [thread overview]
Message-ID: <20250613153304.GA959741@bhelgaas> (raw)
In-Reply-To: <57ad1095-89ba-4044-91ce-1ab37bcc79dd@linux.microsoft.com>
On Thu, Jun 12, 2025 at 09:41:45AM -0700, Graham Whyte wrote:
> On 6/11/2025 11:31 PM, Christoph Hellwig wrote:
> > On Wed, Jun 11, 2025 at 01:08:21PM -0700, Graham Whyte wrote:
> >> We can ask our HW engineers to implement function readiness but we need
> >> to be able to support exiting products, hence why posting it as a quirk.
> >
> > Your report sounds like it works perfectly fine, it's just that you
> > want to reduce the delay. For that you'll need to stick to the standard
> > methods instead of adding quirks, which are for buggy hardware that does
> > not otherwise work.
>
> Bjorn, what would you recommend as next steps here?
This is a tough call and I don't pretend to have an obvious answer. I
understand the desire to improve performance. On the other hand, PCI
has been successful over the long term because devices adhere to
standardized ways of doing things, which makes generic software
possible. Quirks degrade that story, of course, especially when there
is an existing standardized solution that isn't being used. I'm not
at all happy about vendors that decide against the standard solution
and then ask OS folks to do extra work to compensate.
Bjorn
next prev parent reply other threads:[~2025-06-13 15:33 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
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 [this message]
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=20250613153304.GA959741@bhelgaas \
--to=helgaas@kernel.org \
--cc=Okaya@kernel.org \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=code@tyhicks.com \
--cc=grwhyte@linux.microsoft.com \
--cc=hch@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox