On 07/24/2013 05:51 PM, Viresh Kumar wrote: > On 24 July 2013 14:16, Chanwoo Choi <cw00.choi@xxxxxxxxxxx> wrote: >> In case that all CPUs share same cpufreq policy. Each debugfs dentry of CPU[1-3] >> except for CPU0 has symbolic link to CPU0's debugfs directory as following. >> >> -sh-4.1# ls -al /sys/kernel/debug/cpufreq/ >> total 0 >> drwxr-xr-x 3 root root 0 Jan 1 09:00 . >> drwx------ 28 root root 0 Jan 1 09:00 .. >> drwxr-xr-x 2 root root 0 Jan 1 09:00 cpu0 (policy->cpu is 0) >> lrwxrwxrwx 1 root root 0 Jan 1 09:00 cpu1 -> ./cpu0 >> lrwxrwxrwx 1 root root 0 Jan 1 09:00 cpu2 -> ./cpu0 >> lrwxrwxrwx 1 root root 0 Jan 1 09:00 cpu3 -> ./cpu0 >> >> If turn off CPU0 state, I have to move debugfs directory data from cpu0 to cpu1 >> and again create link to cpu1's debugfs directory for CPU[2-3] debugfs directory. >> So, I removed dentry link of CPU[1-3] before creating link again. >> >> cpu1 >> cpu2 -> ./cpu1 >> cpu3 -> ./cpu1 >> >> But I can rewrite new link of CPU[2-3] to previous dentry link(policy->cpu_debugfs[2] or policy->cpu_debugfs[3]) >> for reducing unnecessary code without revmoval sequence. > > Because we aren't freeing the debugfs node at all (just renaming > it), the links might still be good after renaming.. But please check > if it is true. > > So, according to me you need to do this: > - Remove symlink for new policy->cpu, i..e cpu1 in your example > - rename debugfs entry to give it to cpu1 instead of cpu0. > - Set cpu0 pointer to NULL. > > Probably that's it. > And, I add additional step on below: > - Remove symlink for new policy->cpu, i..e cpu1 in your example > - rename debugfs entry to give it to cpu1 instead of cpu0. - Store renamed cpu0 pointer to cpu1 pointer - Create new link for CPU[2-3] to CPU1's debugfs directory because debugfs use string path to create symbolic link. It isn't automatically connected with new CPU1 debugfs directory. > - Set cpu0 pointer to NULL. > Thanks, Chanwoo Choi -- 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