All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Russell Currey <ruscur@russell.cc>, linuxppc-dev@lists.ozlabs.org
Subject: Re: pseries/eeh: Handle RTAS delay requests in configure_bridge
Date: Wed, 23 Mar 2016 11:38:39 +1100 (AEDT)	[thread overview]
Message-ID: <3qV9fR1t3Bz9sDb@ozlabs.org> (raw)
In-Reply-To: <1458606895-24620-1-git-send-email-ruscur@russell.cc>

On Tue, 2016-22-03 at 00:34:55 UTC, 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.
> 
> Signed-off-by: Russell Currey <ruscur@russell.cc>
> ---
>  arch/powerpc/platforms/pseries/eeh_pseries.c | 63 +++++++++++++++++++++-------
>  1 file changed, 47 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
> index ac3ffd9..c5603185 100644
> --- a/arch/powerpc/platforms/pseries/eeh_pseries.c
> +++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
> @@ -614,30 +614,61 @@ static int pseries_eeh_get_log(struct eeh_pe *pe, int severity, char *drv_log, u
>  static int pseries_eeh_configure_bridge(struct eeh_pe *pe)
>  {
>  	int config_addr;
> -	int ret;
> +	int ret = -1;

If possible it's preferable not to pre-initialise your return value.

If you leave it uninitialised then the compiler can (hopefully) detect any
paths where you fail to initialise it.

> +	/* 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;
>  
> -	/* Use new configure-pe function, if supported */
> -	if (ibm_configure_pe != RTAS_UNKNOWN_SERVICE) {
> -		ret = rtas_call(ibm_configure_pe, 3, 1, NULL,
> -				config_addr, BUID_HI(pe->phb->buid),
> -				BUID_LO(pe->phb->buid));
> -	} else if (ibm_configure_bridge != RTAS_UNKNOWN_SERVICE) {
> -		ret = rtas_call(ibm_configure_bridge, 3, 1, NULL,
> -				config_addr, BUID_HI(pe->phb->buid),
> -				BUID_LO(pe->phb->buid));
> -	} else {
> -		return -EFAULT;
> -	}
> +	while (1) {
> +		if (max_wait < 0)
> +			goto err;

Can't you just do:

	while (max_wait > 0) {

?

> +
> +		/* Use new configure-pe function, if supported */
> +		if (ibm_configure_pe != RTAS_UNKNOWN_SERVICE) {
> +			ret = rtas_call(ibm_configure_pe, 3, 1, NULL,
> +					config_addr, BUID_HI(pe->phb->buid),
> +					BUID_LO(pe->phb->buid));
> +		} else if (ibm_configure_bridge != RTAS_UNKNOWN_SERVICE) {
> +			ret = rtas_call(ibm_configure_bridge, 3, 1, NULL,
> +					config_addr, BUID_HI(pe->phb->buid),
> +					BUID_LO(pe->phb->buid));
> +		} else {
> +			return -EFAULT;
> +		}

I realise you've just indented that code, but it would be nice to clean it up
as a precursor patch.

AFAICS the args are identical, so you could just put the token in a variable
and do the rtas_call() once. It also looks like we check at startup that we
have one of the tokens, so we could choose the appropriate token then and avoid
any conditinals in this code.

>  
> -	if (ret)
> -		pr_warn("%s: Unable to configure bridge PHB#%d-PE#%x (%d)\n",
> -			__func__, pe->phb->global_number, pe->addr, ret);
> +		/*
> +		 * If RTAS returns a delay value, it expects software to sleep
> +		 * for 10^x milliseconds.  The max value it can return is thus
> +		 * 10^5 (RTAS_EXTENDED_DELAY_MAX), which is way too long.
> +		 */
>  
> +		switch (ret) {
> +		case 0:
> +			return ret;
> +		case RTAS_EXTENDED_DELAY_MIN:
> +			mwait = 1;
> +			break;
> +		case RTAS_EXTENDED_DELAY_MAX:
> +			mwait = 10;
> +			break;
> +		case RTAS_EXTENDED_DELAY_MIN+2:
> +			mwait = 100;
> +			break;
> +		default:
> +			goto err;
> +		}
> +
> +		max_wait -= mwait;
> +		msleep(mwait);

Can you use rtas_busy_delay() ?

> +	}
> + err:
> +	pr_warn("%s: Unable to configure bridge PHB#%d-PE#%x (%d)\n",
> +		__func__, pe->phb->global_number, pe->addr, ret);
>  	return ret;
>  }


cheers

  parent reply	other threads:[~2016-03-23  0:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-22  0:34 [PATCH] pseries/eeh: Handle RTAS delay requests in configure_bridge Russell Currey
2016-03-23  0:28 ` Russell Currey
2016-03-23  0:38 ` Michael Ellerman [this message]
2016-03-23  2:52   ` Russell Currey
2016-03-23 10:39     ` Michael Ellerman
2016-03-23 23:56       ` Russell Currey

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=3qV9fR1t3Bz9sDb@ozlabs.org \
    --to=mpe@ellerman.id.au \
    --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 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.