From: Gavin Shan <gwshan@linux.vnet.ibm.com>
To: Russell Currey <ruscur@russell.cc>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH V2 2/2] pseries/eeh: Handle RTAS delay requests in configure_bridge
Date: Tue, 29 Mar 2016 20:49:36 +1100 [thread overview]
Message-ID: <20160329094936.GB10585@gwshan> (raw)
In-Reply-To: <1459219911-14110-2-git-send-email-ruscur@russell.cc>
On Tue, Mar 29, 2016 at 12:51:51PM +1000, Russell Currey wrote:
>In the configure_pe and configure_bridge RTAS calls, the spec states
>that values of 9900-9905 can be returned, indicating that software
>should delay for 10^x (where x is the last digit, i.e. 990x)
>milliseconds and attempt the call again. Currently, the kernel doesn't
>know about this, and respecting it fixes some PCI failures when the
>hypervisor is busy.
>
>The delay is capped at 0.2 seconds.
>
When talking about RTAS calls, it might be better to have their full
names defined in PAPR spec. So I guess it'd better to replace configure_pe
and configure_bridge with their corresponding full RTAS call names:
"ibm,configure-pe" and "ibm,configure-bridge".
>Cc: <stable@vger.kernel.org> # 3.10-
I think it would be #3.10+.
>Signed-off-by: Russell Currey <ruscur@russell.cc>
>---
>V2: Use rtas_busy_delay and the new ibm_configure_pe token, refactoring
>---
> arch/powerpc/platforms/pseries/eeh_pseries.c | 35 +++++++++++++++++++++++-----
> 1 file changed, 29 insertions(+), 6 deletions(-)
>
>diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
>index 231b1df..c442b11 100644
>--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
>+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
>@@ -619,20 +619,43 @@ static int pseries_eeh_configure_bridge(struct eeh_pe *pe)
> {
> int config_addr;
> int ret;
>+ /* Waiting 0.2s maximum before skipping configuration */
>+ int max_wait = 200;
>+ int mwait;
>
> /* Figure out the PE address */
> config_addr = pe->config_addr;
> if (pe->addr)
> config_addr = pe->addr;
>
>- ret = rtas_call(ibm_configure_pe, 3, 1, NULL,
>- config_addr, BUID_HI(pe->phb->buid),
>- BUID_LO(pe->phb->buid));
>+ while (max_wait > 0) {
>+ ret = rtas_call(ibm_configure_pe, 3, 1, NULL,
>+ config_addr, BUID_HI(pe->phb->buid),
>+ BUID_LO(pe->phb->buid));
>
>- if (ret)
>- pr_warn("%s: Unable to configure bridge PHB#%d-PE#%x (%d)\n",
>- __func__, pe->phb->global_number, pe->addr, ret);
>+ /*
>+ * RTAS can return a delay value of up to 10^5 milliseconds
>+ * (RTAS_EXTENDED_DELAY_MAX), which is too long. Only respect
>+ * the delay if it's 100ms or less.
>+ */
>
The PAPR spec states that the delay can be up to 10^5ms. The spec also suggests
the maximal delay is 10^2. I guess it's worthy to mention it in the above comments
if you like.
>+ switch (ret) {
>+ case 0:
>+ return ret;
>+ case RTAS_EXTENDED_DELAY_MIN:
>+ case RTAS_EXTENDED_DELAY_MIN+1:
>+ case RTAS_EXTENDED_DELAY_MIN+2:
>+ mwait = rtas_busy_delay(ret);
>+ break;
>+ default:
>+ goto err;
>+ }
>+
>+ max_wait -= mwait;
If you like, the block can be simplified to as below. In that case,
tag #err isn't needed.
if (!ret)
return ret;
max_wait -= rtas_busy_delay(ret);
>+ }
>+err:
>+ pr_warn("%s: Unable to configure bridge PHB#%d-PE#%x (%d)\n",
>+ __func__, pe->phb->global_number, pe->addr, ret);
> return ret;
> }
>
Thanks,
Gavin
next prev parent reply other threads:[~2016-03-29 9:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 2:51 [PATCH V2 1/2] pseries/eeh: Refactor the configure bridge RTAS tokens Russell Currey
2016-03-29 2:51 ` [PATCH V2 2/2] pseries/eeh: Handle RTAS delay requests in configure_bridge Russell Currey
2016-03-29 9:49 ` Gavin Shan [this message]
2016-03-29 22:01 ` Russell Currey
2016-03-29 23:07 ` Gavin Shan
2016-03-29 15:51 ` Tyrel Datwyler
2016-03-29 21:58 ` Russell Currey
2016-03-29 5:26 ` [PATCH V2 1/2] pseries/eeh: Refactor the configure bridge RTAS tokens Gavin Shan
2016-03-29 5:53 ` Russell Currey
2016-03-29 9:26 ` Gavin Shan
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=20160329094936.GB10585@gwshan \
--to=gwshan@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=ruscur@russell.cc \
/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