On 16 November 2013 19:14, Shawn Guo <shawn.guo@xxxxxxxxxx> wrote: > No, it's not a kernel bug. > > OPP is not a definition that belongs to kernel. Instead, it's > characteristics of hardware, and that's why we can naturally put the > definition into device tree. Bear it in mind that device tree is a > hardware description and should be OS agnostic. So it shouldn't be > treated as part of Linux kernel in any case, even though the device > tree source is currently maintained in kernel tree. > > Device tree is designed as a way for firmware/bootloader to describe > hardware to kernel. That said, device tree is more part of bootloader > than kernel. If bootloader runs at a frequency that does not match the > OPP in device tree, the one should be fixed is either bootloader or > device tree but never kernel. I agree for all that.. > However, I agree we should at least have a check in cpufreq-cpu0 driver > and fail out in case that a mismatch is detected. But not here.. We aren't in a non-workable state here.. and so creating panic isn't the right approach. At max we can print an warning but then it doesn't lie in cpufreq-cpu0's domain. It should be done in core if required.. Though for Shawn's information we have another thread in parallel for this issue. You might like to check that too.. https://lkml.org/lkml/2013/11/15/503 -- 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
