All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@intel.com>
To: Sinan Kaya <okaya@codeaurora.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org, timur@codeaurora.org,
	alex.williamson@redhat.com, vikrams@codeaurora.org,
	Lorenzo.Pieralisi@arm.com, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V4] PCI: handle CRS returned by device after FLR
Date: Thu, 13 Jul 2017 13:24:33 -0400	[thread overview]
Message-ID: <20170713172432.GB14716@localhost.localdomain> (raw)
In-Reply-To: <78020acc-c2b6-423c-38a0-251f86ffa8a9@codeaurora.org>

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.

WARNING: multiple messages have this Message-ID (diff)
From: keith.busch@intel.com (Keith Busch)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V4] PCI: handle CRS returned by device after FLR
Date: Thu, 13 Jul 2017 13:24:33 -0400	[thread overview]
Message-ID: <20170713172432.GB14716@localhost.localdomain> (raw)
In-Reply-To: <78020acc-c2b6-423c-38a0-251f86ffa8a9@codeaurora.org>

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.

  reply	other threads:[~2017-07-13 17:18 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-06 21:07 [PATCH V4] PCI: handle CRS returned by device after FLR Sinan Kaya
2017-07-06 21:07 ` Sinan Kaya
2017-07-06 21:07 ` Sinan Kaya
2017-07-13 12:17 ` Bjorn Helgaas
2017-07-13 12:17   ` Bjorn Helgaas
2017-07-13 12:17   ` Bjorn Helgaas
2017-07-13 15:44   ` Sinan Kaya
2017-07-13 15:44     ` Sinan Kaya
2017-07-13 15:44     ` Sinan Kaya
2017-07-13 16:29     ` Keith Busch
2017-07-13 16:29       ` Keith Busch
2017-07-13 16:42       ` Sinan Kaya
2017-07-13 16:42         ` Sinan Kaya
2017-07-13 17:24         ` Keith Busch [this message]
2017-07-13 17:24           ` Keith Busch
2017-07-13 23:38     ` Bjorn Helgaas
2017-07-13 23:38       ` Bjorn Helgaas
2017-07-13 23:38       ` Bjorn Helgaas
2017-07-14 14:10       ` Sinan Kaya
2017-07-14 14:10         ` Sinan Kaya
2017-07-13 16:03   ` Keith Busch
2017-07-13 16:03     ` Keith Busch
2017-07-13 23:49 ` Bjorn Helgaas
2017-07-13 23:49   ` Bjorn Helgaas
2017-07-13 23:49   ` Bjorn Helgaas
2017-07-14 14:28   ` Sinan Kaya
2017-07-14 14:28     ` Sinan Kaya
2017-07-31 21:45   ` Sinan Kaya
2017-07-31 21:45     ` Sinan Kaya
2017-07-31 22:19     ` Bjorn Helgaas
2017-07-31 22:19       ` Bjorn Helgaas
2017-07-31 22:19       ` 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=20170713172432.GB14716@localhost.localdomain \
    --to=keith.busch@intel.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=okaya@codeaurora.org \
    --cc=timur@codeaurora.org \
    --cc=vikrams@codeaurora.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.