On Tue, Oct 8, 2013 at 12:00 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote: >> +static int __init integrator_cpufreq_probe(struct platform_device *pdev) >> { >> + struct device_node *np = pdev->dev.of_node; >> + >> + cm_base = of_iomap(np, 0); >> + if (!cm_base) >> + return -ENODEV; >> return cpufreq_register_driver(&integrator_driver); > > If we fail to register the driver we could unmap cm_base, no? Using devm_* is better so I'll revise it to do this. >> -static void __exit integrator_cpu_exit(void) >> +static void __exit integrator_cpufreq_remove(struct platform_device *pdev) >> { >> cpufreq_unregister_driver(&integrator_driver); > > Unmap here? Dito. Check v2. >> +static const struct of_device_id integrator_cpufreq_match[] = { >> + { .compatible = "arm,core-module-integrator"}, >> + { }, >> +}; > > It feels a little scary that this also got handled by some other code in > the previous patch. Is no arbitrarion required between the two when > accessing the core module registers? They are using totally different registers, so it should not be an issue. Inside the mach folder there is some arbitration for the register that is actually accessed by several consumers. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html