[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250613153304.GA959741@bhelgaas>
Date: Fri, 13 Jun 2025 10:33:04 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Graham Whyte <grwhyte@...ux.microsoft.com>
Cc: Christoph Hellwig <hch@...radead.org>,
Niklas Cassel <cassel@...nel.org>, linux-pci@...r.kernel.org,
shyamsaini@...ux.microsoft.com, code@...icks.com, Okaya@...nel.org,
bhelgaas@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/2] PCI: Reduce FLR delay to 10ms for MSFT devices
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
Powered by blists - more mailing lists