[Skiboot] [PATCH v2 1/2] opal-api: Add OPAL call OPAL_TRIGGER_XSTOP to invoke xstop

[Stewart Smith]

Vipin K Parashar <vipin at linux.vnet.ibm.com> writes:
> This patch adds a new OPAL call OPAL_TRIGGER_XSTOP which will
> be used to invoke xstop. This call invokes xstop by writing to a
> XSCOM register. XSCOM address and FIR bit details are obtained
> via device-tree property 'ibm,sw-checkstop-fir', which contains
> two cells. First cell contains XSCOM address while second cell
> contains FIR bit number. No input parameter is required. Machine
> enters xstop state upon completion of this call.
>
> Signed-off-by: Vipin K Parashar <vipin at linux.vnet.ibm.com>

(after discussing with benh and jk, came up with the following)

Really what we're semantically doing here from a host kernel perspective
is "we cannot possibly continue right now, something has gone terribly
wrong, please collect some debug data and reboot".

So, I was thinking of a call along the lines of:

OPAL_CEC_REBOOT2(enum reboot_type, char *diag, int len)

where reboot_type would be:
0 = normal, equavalent to current OPAL_CEC_REBOOT
1 = unrecoverable platform error
    - typically triggers platform checkstop

and we can leave the other reboot types open for future expansion, for
example, maybe we want to do something with core or unit checkstops in
the future.


For reboot_type != 0, the (null terminated, all up to diag+len recorded)
diag string is stored/forwarded to any attached BMC that is capable of
recording it along with any other debug information that firmware can
trigger saving.

Perhaps we should have reboot_type = 2 for unrecoverable host error
(e.g. hook it up to panic() and BUG_ON() ) ?