xen/arm: psci: Do not keep a rejected PSCI version in psci_ver

psci_init_0_2() stores the value returned by PSCI_VERSION in the global
psci_ver before checking that Xen supports it. When the firmware reports
a version other than 0.2 or 1.x, the function prints "Unrecognized PSCI
version" and returns -EOPNOTSUPP, but psci_ver keeps the rejected value
and psci_cpu_on_nr stays 0.

psci_init() then tries the PSCI 0.1 fallback, which overwrites psci_ver
on success. When the fallback fails as well (the /psci node is not
compatible with "arm,psci", it has no "cpu_on" property, or Xen boots
with ACPI), psci_init() returns an error that smp_init_cpus() ignores,
and psci_ver still holds the rejected version. All the users of
psci_ver then consider PSCI as available:
 - on arm64, smp_psci_init() installs call_psci_cpu_on() as the method
   to bring up the secondary CPUs;
 - on arm32, platform_cpu_up() calls call_psci_cpu_on() instead of the
   platform specific cpu_up() callback;
 - call_psci_cpu_off(), call_psci_system_off() and
   call_psci_system_reset() issue their PSCI calls.

As a result, Xen brings up each secondary CPU with an SMC using function
ID 0. An SMCCC compliant firmware refuses it, and Xen reports "Failed to
bring up CPU<n> (error -1)" for each secondary CPU.

Fix it by setting psci_ver back to 0 before returning the error.

Fixes: 4d3d72c014 ("xen/arm: Initial support for PSCI-0.2")
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

xen/arch/arm/psci.c

@@ -198,6 +198,7 @@ static int __init psci_init_0_2(void)
     {
         printk("Error: Unrecognized PSCI version %u.%u\n",
                PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
+        psci_ver = 0;
         return -EOPNOTSUPP;
     }