Hi guys, I will answer to questions of both of you in this mail. On 22 March 2013 18:23, Thomas Renninger <trenn@xxxxxxx> wrote: > Is this all to try to fix "cpufreq driver gets loaded while some cores > were set offline before"? Not really. There are problems with acpi-cpufreq without that case too. > I wonder how you run into "cpufreq is initialized with offlined cpus" case. > I remember that there were problems, but it's nearly impossible to run > into this if the cpufreq driver is loaded early at boot. I always thought there is a way not to boot all cpus by passing stuff in command line and so this is a easy case to reproduce. > cpufreq_add_dev() and friends are complicated. Not anymore, they are hugely simplified now. > Those init functions got split some time ago and there also slipped > in a bug even it was simple splitting of functions. > > I do not have time to look at fcf8058296edbc3de43adf095824fc32b067b9f8 > right now. Don't know how much other stuff depends on it and how > sever it is on ARM that cpufreq does not correctly initialize with offlined > cpus..., I would revert this patch. Let me clear it to everybody. There isn't/shouldn't be a bug in cpufreq core, its just that acpi-cpufreq driver isn't adapted well with the changes related to affected_cpus and related_cpus. I have never gone into coding for any non-ARM platform and am really not aware of acpi-cpufreq driver and its users. That's why i told everybody where the issue is, and they just need to fix acpi-cpufreq driver with right values of policy->cpus (affected_cpus) and everything else would work after that. -- 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
