[Adding lakml and others with an interest in PSCI 0.2]

> +     pr_info("using static PSCI Function ID's\n");

It's probably worth stating which static IDs are in use, e.g. "using
standard PSCI 0.2 function IDs". Later versions might get more
functions, and being explicit from the start will make debugging easier
across kernel versions.

Also, it would be good to print out the return value of PSCI_VERSION to
notify the user which version of PSCI the implementation claims to be
conformant with.

> +     psci_function_id[PSCI_FN_MIGRATE] = PSCI_ID_CPU_MIGRATE;
> +     psci_ops.migrate = psci_migrate;

It would also be a good idea to hook up AFFINITY_INFO to a cpu_kill
callback from the start, to ensure implementors bother to implement it,
and such that we can make kexec safe(r).

If we rely on it from the start it's more likely that it will actually
get implemented, and it will highlight any dodgy PSCI 0.2
implementations while there's a chance they can be fixed.

> -             pr_warning("missing \"method\" property\n");
> +             pr_warn("missing \"method\" property\n");

Unrelated change? (not that I'm against it).

> +static const struct of_device_id psci_of_match[] __initconst = {
> +     { .compatible = "arm,psci", .data = psci_of_init},
> +     { .compatible = "arm,psci-0.2", .data = psci_static_init},

This requires a binding document update, explaining exactly what this
string implies.

> +     init_fn = (psci_initcall_t)matched_np->data;

Is an explicit cast necessary here?

My comments for the 32-bit version apply here too.