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