On 27 January 2013 22:47, Andrew Lunn <andrew@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
