Hi Mark,
On 14 March 2014 05:52, Mark Rutland mark.rutland@arm.com wrote:
[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.
Good idea.
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.
Ok.
pr_warning("missing \"method\" property\n");
pr_warn("missing \"method\" property\n");Unrelated change? (not that I'm against it).
checkpatch raised 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.
Ok.
init_fn = (psci_initcall_t)matched_np->data;Is an explicit cast necessary here?
Hm. I guess I added it because of void * data. Not needed. Will remove.
My comments for the 32-bit version apply here too.
Thanks for the quick review. I'll respin it in a day or so. Hopefully others get a chance to look at it in the mean time.
Cheers, Ashwin