[Skiboot] [PATCH] powerpc/powernv/nvram: opal_nvram_write handle unknown OPAL errors

[Nicholas Piggin]

On Tue, 27 Mar 2018 12:47:31 +0530
Vasant Hegde <hegdevasant at 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 <npiggin at 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