From: Sinan Kaya <okaya@kernel.org>
To: "Raj, Ashok" <ashok.raj@intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
"Spassov, Stanislav" <stanspas@amazon.de>,
"corbet@lwn.net" <corbet@lwn.net>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"Wang, Wei" <wawei@amazon.de>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"Schoenherr, Jan H." <jschoenh@amazon.de>,
"rajatja@google.com" <rajatja@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH 1/3] PCI: Make PCIE_RESET_READY_POLL_MS configurable
Date: Mon, 2 Mar 2020 13:30:44 -0500 [thread overview]
Message-ID: <885cef84-575b-b564-f5b4-75848486466c@kernel.org> (raw)
In-Reply-To: <20200302173728.GA77115@otc-nc-03>
On 3/2/2020 12:37 PM, Raj, Ashok wrote:
>> 1 second is too aggressive. We already have proof that several PCIe
>> cards take their time during FLR especially FPGA cards in the orders
>> of 10 seconds.
> Aren't the rules specified in 7.9.17 Rediness Time Reporting Extended Capability
> sufficient to cover this?
>
Yes, readiness would work too but it is not a mandatory feature.
Readiness is yet another alternative to CRS advertised as the new
flashy way of doing things. Problem is backwards compatibility.
Do you want to break all existing/legacy drivers for an optional/new
spec defined feature?
> If a device doesn't have them we could let the driver supply this value
> as a device specific value to override the default.
>
>> Current code is waiting up to 60 seconds. If card shows up before that
>> we happily return.
>>
> But in 7.9.17.2 Readiness Time Reporting 1 Register, says devices
> can defer reporting by not setting the valid bit, but if it remains
> clear after 60s system software can assume no valid values will be reported.
>
> Maybe keep the system default to something more reasonable (after some
> testing in the community), and do this insane 60s for devices that
> support the optional reporting capability?
I think we should add readiness capability on top of CRS but not
exclusively.
If readiness is supported, do the spec defined behavior.
If not supported, fallback to CRS for legacy devices.
I remember Bjorn mentioning about readiness capability. Maybe, this is
the time to implement it.
next prev parent reply other threads:[~2020-03-02 18:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-23 12:20 [PATCH 0/3] Improve PCI device post-reset readiness polling Stanislav Spassov
2020-02-23 12:20 ` [PATCH 1/3] PCI: Make PCIE_RESET_READY_POLL_MS configurable Stanislav Spassov
2020-02-24 14:15 ` Bjorn Helgaas
2020-02-24 17:52 ` Spassov, Stanislav
2020-02-27 21:45 ` Bjorn Helgaas
2020-02-27 23:44 ` Sinan Kaya
2020-02-28 2:18 ` Raj, Ashok
2020-03-02 16:39 ` Sinan Kaya
2020-03-02 17:37 ` Raj, Ashok
2020-03-02 18:30 ` Sinan Kaya [this message]
2020-02-23 12:20 ` [PATCH 2/3] PCI: Introduce per-device reset_ready_poll override Stanislav Spassov
2020-02-24 14:34 ` Bjorn Helgaas
2020-02-24 18:05 ` Spassov, Stanislav
2020-02-23 12:20 ` [PATCH 3/3] PCI: Add CRS handling to pci_dev_wait() Stanislav Spassov
2020-02-24 20:41 ` Bjorn Helgaas
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=885cef84-575b-b564-f5b4-75848486466c@kernel.org \
--to=okaya@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=corbet@lwn.net \
--cc=helgaas@kernel.org \
--cc=jschoenh@amazon.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rajatja@google.com \
--cc=stanspas@amazon.de \
--cc=tglx@linutronix.de \
--cc=wawei@amazon.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).