Hey, how does this new patch square with commit 9e76988e9390a4ff4d171f690586d0c58186b47e Author: Venki Pallipadi <venkatesh.pallipadi@xxxxxxxxx> Date: Fri Oct 26 10:18:21 2007 -0700 [CPUFREQ] Eliminate cpufreq_userspace scaling_setspeed deadlock ... There seems to be no easy way to avoid this deadlock as long as cpufreq_userspace adds/removes the sysfs entry under same kobject as cpufreq. Below patch moves scaling_setspeed to cpufreq.c, keeping it always and calling back the governor on read/write. This is the cleanest fix I could think of, even though adding two callbacks in governor structure just for this seems unnecessary. Note that the change makes scaling_setspeed under /sys/.../cpufreq permanent and returns <unsupported> when governor is not userspace. ... I.e. -- could the deadlock situation still occur? Best, Dominik PS: what are the merging plans wrt one-governor-per-system? I.e., when should I fix cpufrequtils / libcpufreq? -- 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
