Re: [PATCH 6/6] cpufreq: probe the Integrator cpufreq driver from DT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux