[Skiboot] [PATCH] fsp: return OPAL_BUSY_EVENT on failure sending FSP_CMD_POWERDOWN_NORM

[Vasant Hegde]

On 10/09/2017 11:48 AM, Stewart Smith wrote:
> Vasant Hegde <hegdevasant at linux.vnet.ibm.com> writes:
>>> --- a/platforms/ibm-fsp/common.c
>>> +++ b/platforms/ibm-fsp/common.c
>>> @@ -223,7 +223,7 @@ int64_t ibm_fsp_cec_power_down(uint64_t request)
>>>  	printf("FSP: Sending shutdown command to FSP...\n");
>>
>> We may endup filling OPAL console with above message as kernel will repeatedly
>> makes shutdown call.
>
> Yeah, at least that's not user visible though?

Yes. Its not user visible. But OPAL msglog will be full of these messages and 
may not be useful for any debugging.. May be that's fine.

>
>>>  	if (fsp_sync_msg(fsp_mkmsg(FSP_CMD_POWERDOWN_NORM, 1, request), true))
>>
>> How about changing this to fsp_queue_msg?  Even in shutdown path we will be able
>> to queue message and send it to FSP after R/R completes.
>
> If we have a pending firmware update though, we'll have all CPUs in OPAL
> with interrupts off, so we do have to go and run pollers to have a
> chance of making forward progress. Even though we'd never apply the
> update due to R/R, (not that I think we've ever tested this exact
> scenario), we would still go down that code path in the kernel.

Yeah. I don't think we ever tested codeupdate with FSP R/R. But with this change 
we will keep on retrying codeupdate as well (along with sending shutdown 
message). Once FSP is back it will try to start codeupdate. that should be fine 
I guess.

-Vasant

>
> In that case, we'd still have to return OPAL_BUSY_EVENT so we could
> reconnect and process the queued message, so it really wouldn't make
> much of a difference (in fact, we'd have to keep track on if we've
> queued it or not).
>