[Skiboot] [PATCH] fsp: Don't recurse pollers in ibm_fsp_terminate
hegdevasant at linux.vnet.ibm.com
Fri Nov 18 21:26:43 AEDT 2016
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)
call default opal poller
return __fsp_sync_msg(...., true);
More information about the Skiboot