On Tue, 27 Mar 2018 12:47:31 +0530 Vasant Hegde <hegdevas...@linux.vnet.ibm.com> wrote:
> On 03/26/2018 08:32 PM, Nicholas Piggin wrote: > > opal_nvram_write currently just assumes success if it encounters an > > error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO > > on other errors instead. > > > > Signed-off-by: Nicholas Piggin <npig...@gmail.com> > > --- > > arch/powerpc/platforms/powernv/opal-nvram.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/powerpc/platforms/powernv/opal-nvram.c > > b/arch/powerpc/platforms/powernv/opal-nvram.c > > index 9db4398ded5d..13bf625dc3e8 100644 > > --- a/arch/powerpc/platforms/powernv/opal-nvram.c > > +++ b/arch/powerpc/platforms/powernv/opal-nvram.c > > @@ -59,6 +59,8 @@ static ssize_t opal_nvram_write(char *buf, size_t count, > > loff_t *index) > > if (rc == OPAL_BUSY_EVENT) > > opal_poll_events(NULL); > > Current code does continuous poller here. May be we have small breathing time > here. What you say? Yeah that's probably not a bad idea. I cc'ed skiboot list -- what's a reasonable delay between retries? Linux has a bunch of similar kind of loops if you grep for opal_poll_events and OPAL_BUSY. It would be good to convert them all to a standard form with a standard delay as recommended by OPAL, and where specific calls have different delay for a good reason, that would be documented in the OPAL API docs. Thanks, Nick
