linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Spassov, Stanislav" <stanspas@amazon.de>
To: "helgaas@kernel.org" <helgaas@kernel.org>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"ashok.raj@intel.com" <ashok.raj@intel.com>,
	"okaya@kernel.org" <okaya@kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"Schönherr, Jan H." <jschoenh@amazon.de>,
	"rajatja@google.com" <rajatja@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>
Subject: Re: [PATCH v4 2/3] PCI: Cache CRS Software Visibiliy in struct pci_dev
Date: Mon, 13 Sep 2021 16:06:12 +0000	[thread overview]
Message-ID: <e0bc9f1409470a1e7c30fc92cd6938ebae1ac31a.camel@amazon.de> (raw)
In-Reply-To: <20210912133246.GA1279483@bjorn-Precision-5520>

On Sun, 2021-09-12 at 08:32 -0500, Bjorn Helgaas wrote:
> On Sat, Mar 07, 2020 at 06:20:43PM +0100, Stanislav Spassov wrote:
> > However, storing the flag in struct pci_dev allows individual devices
> > to be marked as not supporting CRS properly even when CRS SV is enabled
> > on their parent Root Port. This way, future code that relies on the new
> > flag will not be misled that it is safe to probe a device by relying on
> > CRS SV to not cause platform timeouts (See the note on CRS SV on p. 553
> > of PCI Express Base Specification r5.0 from May 22, 2019).
> 
> If we find devices that don't support CRS properly, I think we should
> quirk them directly with something other than "crssv_enabled".

I am definitely open to suggestions here. Based on precedent such as the
broken_intx_masking field in struct pci_dev and how it is set from
pci/quirks.c, we could have a new field "broken_crs".

In hindsight, the code from PATCH 3/3 which is conditionally executed based
on this flag, should be okay to execute unconditionally: polling the Vendor
ID is safer than polling Command when CRS SV is enabled but it is still not
any more dangerous when CRS SV is disabled. This consideration allows us
to drop the current PATCH 2/3 altogether. I will implement this approach in
the next reversion of the series (it is old and needs rebasing anyway).



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



  reply	other threads:[~2021-09-13 16:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-07 17:20 [PATCH v4 0/3] Improve PCI device post-reset readiness polling Stanislav Spassov
2020-03-07 17:20 ` [PATCH v4 1/3] PCI: Refactor polling loop out of pci_dev_wait Stanislav Spassov
2020-03-07 17:20 ` [PATCH v4 2/3] PCI: Cache CRS Software Visibiliy in struct pci_dev Stanislav Spassov
2021-09-12 13:32   ` Bjorn Helgaas
2021-09-13 16:06     ` Spassov, Stanislav [this message]
2020-03-07 17:20 ` [PATCH v4 3/3] PCI: Add CRS handling to pci_dev_wait() Stanislav Spassov
2020-03-09 15:55   ` Sinan Kaya
2020-03-09 16:19     ` Raj, Ashok
2020-03-09 16:38       ` Spassov, Stanislav
2020-03-09 17:33         ` Sinan Kaya
2021-09-11 14:03   ` Bjorn Helgaas
2021-09-13 16:29     ` Spassov, Stanislav
2021-09-13 16:38       ` Bjorn Helgaas
2021-09-13 18:04         ` Spassov, Stanislav
2021-09-14 17:53           ` Rajat Jain
2021-09-13 16:07   ` Bjorn Helgaas
2021-09-13 16:39     ` Spassov, Stanislav
2021-01-22  8:54 ` [PATCH v4 0/3] Improve PCI device post-reset readiness polling David Woodhouse
2021-09-10  9:32   ` David Woodhouse

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=e0bc9f1409470a1e7c30fc92cd6938ebae1ac31a.camel@amazon.de \
    --to=stanspas@amazon.de \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=helgaas@kernel.org \
    --cc=jschoenh@amazon.de \
    --cc=linux-pci@vger.kernel.org \
    --cc=okaya@kernel.org \
    --cc=rajatja@google.com \
    --cc=tglx@linutronix.de \
    /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).