LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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