[PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs

[Viresh Kumar]

On 27 January 2013 22:47, Andrew Lunn <andrew at lunn.ch> wrote:
> I expect Debian, Fedora etc will strongly disagree with you
> there. They want one kernel that will run on as many products they
> support as possible. Kirkwood is mostly used in NAS boxes and is
> supported by all these distributions.
>
> Now for a SoC used in a deeply embedded system, using a custom
> distribution, buildroot, etc, multiplatform is probably not
> wanted. But the products i've seen using Kirkwood don't fit this use
> case.

Accepted. I was wrong with my comment here :)

>> So, even this kind of delay is really not a big issue. On the other
>> hand with platform driver too, we will hit lot of other code and
>> would consume some extra memory for keeping its structures
>
> Kirkwood has many platform drivers, all this code is already pulled
> in, lots of structures already exist. The incremental costs of another
> platform device is minimal.

Its about delay executing other code too for platform device.

Other than that, there is one more issue with this style. It against DT
philosophy. :(

We really shouldn't add any devices from arch/arm/mach-* for any new
drivers. And when we have DT support in driver, then it doesn't make
any sense. So, you really need to pass this from cpu node in DT.

--
viresh