On 19 November 2013 07:51, Shawn Guo <shawn.guo@xxxxxxxxxx> wrote: > No, I did not say that. IMO, when cpufreq-cpu0 sees a mismatch, it has > no way to know or assume which one is correct and which is incorrect. > The best thing it can do is to fail out without changing anything about > running frequency and voltage. Not specifically on this patch, but this is what I feel about this issue: - As we are discussing on the other thread, there is scope of adding "unknown" field in tables so that people would know that they were running out of table freq at some point.. - This is a common problem for all drivers/platforms and not only cpufreq-cpu0, so the solution has to be generic and not driver specific.. So, atleast I don't want to get this patch in at any cost, unless there is a generic solution present.. - There are non-dt drivers as well, and so freq table is present with the kernel and we can't support all frequencies that bootloader may end up with.. -- 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
