On 26 November 2013 02:43, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > On Monday, November 25, 2013 09:43:59 AM Dirk Brandewie wrote: >> This is a platform specific bug fix AFAICT and belongs in a platform >> specific piece of code In case we end up doing that, we will do lots of code redundancy in cpufreq drivers. And as Rafael said, some platforms might never know they have booted with an out of table frequency and so taking care of this at a single place is better, where we are sure that it will get fixed. >> The core should not be working around bootloader bugs IMHO. Silently >> fixing it is evil IMHO at a minimum the core should complain LOUDLY >> about this happening otherwise the bootloaders will have no incentive to >> get their act together. That looks correct.. > Yes, we can add a WARN_ON() there. Still, though, the core's responsibility > is to ensure that (a) either we can continue safely or (b) we can't, in which > case it should just fail the initialization. Whether or not it should panic() > I'm not sure. But is this that big crime, that we do a WARN on it? CPU was running on a workable frequency, it wasn't mentioned in the table, that's it. Probably just throw an print message that CPU found to be running on out of table frequency, and that got fixed.. -- 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
