[PATCH] powerpc/powernv: Fallback to old HMI handling behavior for old firmware

[Stewart Smith]

Mahesh J Salgaonkar <mahesh at linux.vnet.ibm.com> writes:
> From: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
>
> Recently we moved HMI handling into Linux kernel instead of taking
> HMI directly in OPAL. This new change is dependent on new OPAL call
> for HMI recovery which was introduced in newer firmware. While this new
> change works fine with latest OPAL firmware, we broke the HMI handling
> if we run newer kernel on old OPAL firmware that results in system hang.
>
> This patch fixes this issue by falling back to old HMI behavior on older
> OPAL firmware.
>
> This patch introduces a check for opal token OPAL_HANDLE_HMI to see
> if we are running on newer firmware or old firmware. On newer firmware
> this check would return OPAL_TOKEN_PRESENT, otherwise we are running on
> old firmware and fallback to old HMI behavior.
>
> This patch depends on opal check token patch posted at ppc-devel
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120224.html

(just reviewed that patch before this one...)

> diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
> index b44eec3..2768cd3 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -194,6 +194,24 @@ static int __init opal_register_exception_handlers(void)
>  	 * fwnmi area at 0x7000 to provide the glue space to OPAL
>  	 */
>  	glue = 0x7000;
> +
> +	/* Check if we are running on newer firmware that exports
> +	 * OPAL_HANDLE_HMI token. If yes, then don't ask opal to patch
> +	 * HMI interrupt and we catch it directly in Linux kernel.
> +	 *
> +	 * For older firmware we will fallback to old behavior and
> +	 * let OPAL patch the HMI vector and handle it inside OPAL
> +	 * firmware.
> +	 */
> +	if (opal_check_token(OPAL_HANDLE_HMI) != OPAL_TOKEN_PRESENT) {
> +		/* We are on old firmware. fallback to old behavior. */
> +		pr_info("%s: Falling back to old HMI handling behavior.\n",
> +			__func__);
> +		opal_register_exception_handler(
> +				OPAL_HYPERVISOR_MAINTENANCE_HANDLER,
> +				0, glue);
> +		glue += 128;
> +	}
>  	opal_register_exception_handler(OPAL_SOFTPATCH_HANDLER, 0,
> glue);

So.. that all looks fine, but another note: why are we doing the
OPAL_SOFTPATCH_HANDLER and why is it all #if 0 out in skiboot?

for this patch:

Reviewed-by: Stewart Smith <stewart at linux.vnet.ibm.com>