Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1686787

Re: [PATCH V4] PCI: handle CRS returned by device after FLR

From Keith Busch <keith.busch@intel.com>
Newsgroups linux.kernel
Subject Re: [PATCH V4] PCI: handle CRS returned by device after FLR
Date 2017-07-13 19:20 +0200
Message-ID <u2PWp-8rc-3@gated-at.bofh.it> (permalink)
References <u0mca-2zL-21@gated-at.bofh.it> <u2Lg6-5xB-13@gated-at.bofh.it> <u2OH0-7vy-7@gated-at.bofh.it> <u2Pa3-7UJ-27@gated-at.bofh.it> <u2Ptn-813-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Jul 13, 2017 at 12:42:44PM -0400, Sinan Kaya wrote:
> On 7/13/2017 12:29 PM, Keith Busch wrote:
> > That wording is just confusing. It looks to me the 1 second polling is
> > to be used following a reset if CRS is not implemented.
> > 
> >   https://pcisig.com/sites/default/files/specification_documents/ECN_RN_29_Aug_2013.pdf
> > 
> > "
> >   Through the mechanisms defined by this ECR, we can avoid the long,
> >   architected, fixed delays following various forms of reset before
> >   software is permitted to perform its first Configuration Request. These
> >   delays are very large:
> > 
> >   1 second if Configuration Retry Status (CRS) is not used
> > "
> > 
> > It goes on to say CRS is usually much lower, but doesn't specify an
> > upper bound either.
> > 
> 
> I see, we got caught on spec language where we don't know what 'its' is. 

Well, I don't know for certain if your original interpretation is
incorrect. Just saying the CRS intention doesn't explicitly stand out to me.

On a side note, I'll also see if I can get clarification on what
expectations the hardware people have for this particular product. Your
observation seems a little high to me, but I don't know if that's
outside the product's limits.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH V4] PCI: handle CRS returned by device after FLR Sinan Kaya <okaya@codeaurora.org> - 2017-07-06 23:10 +0200
  Re: [PATCH V4] PCI: handle CRS returned by device after FLR Bjorn Helgaas <helgaas@kernel.org> - 2017-07-13 14:20 +0200
    Re: [PATCH V4] PCI: handle CRS returned by device after FLR Sinan Kaya <okaya@codeaurora.org> - 2017-07-13 18:00 +0200
      Re: [PATCH V4] PCI: handle CRS returned by device after FLR Keith Busch <keith.busch@intel.com> - 2017-07-13 18:30 +0200
        Re: [PATCH V4] PCI: handle CRS returned by device after FLR Sinan Kaya <okaya@codeaurora.org> - 2017-07-13 18:50 +0200
          Re: [PATCH V4] PCI: handle CRS returned by device after FLR Keith Busch <keith.busch@intel.com> - 2017-07-13 19:20 +0200
      Re: [PATCH V4] PCI: handle CRS returned by device after FLR Bjorn Helgaas <helgaas@kernel.org> - 2017-07-14 01:40 +0200
        Re: [PATCH V4] PCI: handle CRS returned by device after FLR Sinan Kaya <okaya@codeaurora.org> - 2017-07-14 16:20 +0200
    Re: [PATCH V4] PCI: handle CRS returned by device after FLR Keith Busch <keith.busch@intel.com> - 2017-07-13 18:00 +0200
  Re: [PATCH V4] PCI: handle CRS returned by device after FLR Bjorn Helgaas <helgaas@kernel.org> - 2017-07-14 01:50 +0200
    Re: [PATCH V4] PCI: handle CRS returned by device after FLR Sinan Kaya <okaya@codeaurora.org> - 2017-07-14 16:30 +0200

csiph-web