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

On Wed, 2016-03-23 at 11:38 +1100, Michael Ellerman wrote:
> 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.
> 
Relic of a previous iteration, my bad.
> > 
> > +	/* 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) {
> 
> ?
...yes.
> 
> > 
> > +
> > +		/* 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.

Yes, good idea.
> 
> > 
> >  
> > -	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() ?

Wasn't aware of that, makes life a lot easier.  Do you know if the 0.2s
maximum delay also applies across the board?  I definitely want to enforce
it here, but if it is ubiquitous then it should be in 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

  reply	other threads:[~2016-03-23  2:52 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
2016-03-23  2:52   ` Russell Currey [this message]
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=1458701571.5945.8.camel@russell.cc \
    --to=ruscur@russell.cc \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /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.