Nicholas Piggin writes:
> 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
> ---
> arch/powerpc/platforms/powernv/opal-nvram.c | 2 ++
> 1 file ch
On 03/27/2018 01:08 PM, Nicholas Piggin wrote:
On Tue, 27 Mar 2018 12:47:31 +0530
Vasant Hegde 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
unscribed me
On Tuesday, March 27, 2018 05:34:30 AM PDT, Michael
Ellerman wrote:
Nicholas Piggin writes:
> 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 inst
On Tue, 27 Mar 2018 23:13:00 +1100
Michael Ellerman wrote:
> Nicholas Piggin writes:
>
> > 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.
>
> Does that ever happen with cu
Nicholas Piggin writes:
> 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.
Does that ever happen with current skiboot?
Even if it doesn't I think I'm inclined to tag this for stabl
On Tue, 27 Mar 2018 12:47:31 +0530
Vasant Hegde 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-b
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
---
arch/powerpc/platforms/powernv/opal-nvram.c | 2 ++
