From: Gregory Price <gourry@gourry.net>
To: Lukas Wunner <lukas@wunner.de>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Dan Williams <dan.j.williams@intel.com>,
linux-pci@vger.kernel.org, linux-cxl@vger.kernel.org,
linux-kernel@vger.kernel.org, bhelgaas@google.com,
dave@stgolabs.net, dave.jiang@intel.com,
vishal.l.verma@intel.com
Subject: Re: [PATCH] pci/doe: add a 1 second retry window to pci_doe
Date: Tue, 1 Oct 2024 12:04:43 -0400 [thread overview]
Message-ID: <Zvwdmy43AUELFzV4@PC2K9PVX.TheFacebook.com> (raw)
In-Reply-To: <ZvwZd5CCV2PdqSLF@wunner.de>
On Tue, Oct 01, 2024 at 05:47:03PM +0200, Lukas Wunner wrote:
> On Tue, Oct 01, 2024 at 11:13:17AM -0400, Gregory Price wrote:
> > > > Gregory Price wrote:
> > > > > Depending on the device, sometimes firmware clears the busy flag
> > > > > later than expected. This can cause the device to appear busy when
> > > > > calling multiple commands in quick sucession. Add a 1 second retry
> > > > > window to all doe commands that end with -EBUSY.
> >
> > Just following up here, it sounds like everyone is unsure of this change.
> >
> > I can confirm that this handles the CDAT retry issue I am seeing, and that
> > the BUSY bit is set upon entry into the initial call. Only 1 or 2 retries
> > are attempted before it is cleared and returns successfully.
> >
> > I'd explored putting the retry logic in the CDAT code that calls into here,
> > but that just seemed wrong. Is there a suggestion or a nak here?
> >
> > Trying to find a path forward.
>
> The PCIe Base Spec doesn't prescribe a maximum timeout for the
> DOE BUSY bit to clear. Thus it seems fine to me in principle
> to add a (or raise the) timeout if it turns out to be necessary
> for real-life hardware.
>
> That said, the proposed patch has room for improvement:
Will address and resubmit, thanks!
>
> * The patch seems to wait for DOE BUSY bit to clear *after*
> completion. That's odd. The kernel waits for DOE Busy bit
> to clear *before* sending a new request, in pci_doe_send_req().
> My expectation would have been that you'd add a loop there which
> polls for DOE Busy bit to clear before sending a request.
>
> It seems that polling is the only option as no interrupt is
> raised on DOE Busy bit clear, per PCIe r6.2 sec 6.30.3.
> (Please add this bit of information to the commit message.)
>
> * The commit message should clearly specify the device(s)
> affected by the issue (Vendor and Device ID plus name).
> Comments such as "Depending on the device, sometimes ..."
> are a little too vague.
>
> * The "1 or 2 retries" bit of information you're mentioning
> above should likewise be in the commit message.
>
> * Please use "PCI/DOE:" as subject prefix to match previous
> commits which touched drivers/pci/doe.c.
>
> * Please adhere to spec language, e.g. use "DOE Busy bit"
> instead of "busy bit" so it's unambiguous for readers
> what you're referring to.
>
> Thanks,
>
> Lukas
next prev parent reply other threads:[~2024-10-01 16:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 18:32 [PATCH] pci/doe: add a 1 second retry window to pci_doe Gregory Price
2024-09-14 5:32 ` Dan Williams
2024-09-16 9:15 ` Jonathan Cameron
2024-10-01 15:13 ` Gregory Price
2024-10-01 15:47 ` Lukas Wunner
2024-10-01 16:04 ` Gregory Price [this message]
2024-10-04 11:32 ` Jonathan Cameron
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=Zvwdmy43AUELFzV4@PC2K9PVX.TheFacebook.com \
--to=gourry@gourry.net \
--cc=Jonathan.Cameron@huawei.com \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=vishal.l.verma@intel.com \
/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