[Skiboot] [PATCH] fsp: Don't recurse pollers in ibm_fsp_terminate

[Vasant Hegde]

On 11/18/2016 09:28 AM, Stewart Smith wrote:
> If we were to terminate in a poller, we'd call op_display() which
> called pollers which hit the recursive poller warning, which ended
> in not much fun at all.
>
> This patch will skip the running of pollers and instead run
> the FSP poller to set the op-panel display before attn.
>
> Signed-off-by: Stewart Smith <stewart at linux.vnet.ibm.com>
> ---
>   hw/fsp/fsp-op-panel.c |  8 +++++++-
>   hw/fsp/fsp.c          | 31 +++++++++++++++++++++++++++++++
>   include/fsp.h         |  7 +++++++
>   3 files changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/hw/fsp/fsp-op-panel.c b/hw/fsp/fsp-op-panel.c
> index eb61e8d..7063cbb 100644
> --- a/hw/fsp/fsp-op-panel.c
> +++ b/hw/fsp/fsp-op-panel.c
> @@ -40,7 +40,13 @@ static void fsp_op_display_fatal(uint32_t w0, uint32_t w1)
>
>   	fsp_fillmsg(&op_msg, FSP_CMD_DISP_SRC_DIRECT, 3, 1, w0, w1);
>
> -	fsp_sync_msg(&op_msg, false);
> +	/*
> +	 * A special way to send a message: it doesn't run pollers.
> +	 * This means we can call it while in a poller, which we may
> +	 * well be in when we're terminating (and thus displaying a *fatal*
> +	 * message on the op-panel).
> +	 */
> +	fsp_fatal_msg(&op_msg);

So we call this function for FATAL errors only.. That means most likely we are 
in PANIC path (like abort).  Do we really need to wait till we send message to 
FSP. Can't we just queue and proceed? Of course we have a side effect of message 
not completing ..

Assuming we really want this message to complete, I see below function is 
duplicate of fsp_sync_message except that you are calling fsp poller here..


May be we should abstract it something like below ?

__fsp_sync_msg(...., bool opal_poller)
{

....
   if (opal_poller)
		call default opal poller
   else
		call fsp_poller

}


fsp_sync_msg(...)
{
    return __fsp_sync_msg(...., true);

}


-Vasant