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

[Vasant Hegde]

On 03/27/2018 01:08 PM, Nicholas Piggin wrote:
> 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?

I think it depends on individual API. Like in case of dump retrival I've 20ms 
delay... as FSP takes time to copy data to host memory. But may be here we can 
have smaller delay.

> 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.

Yes. We should update API documentation.

-Vasant