| Message ID | 20150213094514.12351.11666.stgit@localhost.localdomain (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 3f77df7f81526c932ef681eda56eeaa75d0617da |
| Headers | show |
diff --git a/arch/powerpc/platforms/powernv/opal-flash.c b/arch/powerpc/platforms/powernv/opal-flash.c index 5c21d9c..0ff07ff 100644 --- a/arch/powerpc/platforms/powernv/opal-flash.c +++ b/arch/powerpc/platforms/powernv/opal-flash.c @@ -120,7 +120,11 @@ static struct image_header_t image_header; static struct image_data_t image_data; static struct validate_flash_t validate_flash_data; static struct manage_flash_t manage_flash_data; -static struct update_flash_t update_flash_data; + +/* Initialize update_flash_data status to No Operation */ +static struct update_flash_t update_flash_data = { + .status = FLASH_NO_OP, +}; static DEFINE_MUTEX(image_data_mutex);
Present code checks for update_flash_data in opal_flash_term_callback(). update_flash_data has been statically initialized to zero, and that is the value of FLASH_IMG_READY. Also code update initialization happens during subsys init. So if reboot is issued before the subsys init stage then we endup displaying "Flashing new firmware" message.. which may confuse end user. This patch fixes above described issue by initializes update_flash status to invalid state. Reported-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> --- Ben, Sam, How about this patch? Initially I though of changing FLASH_IMG_READY value. But it has a impact on user space tool. (update_flash checks this value before calling reboot. See update_show function. Of course we can work around that .. But I thought this one is simpler approach. -Vasant arch/powerpc/platforms/powernv/opal-flash.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)