/sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq has file mode 400, while other cpu related files are 444. Non-sudoers cannot read current frequency scaling.
This also doesn't make sense to me. I will send a patch to change it and see other guys' comment.
You can read current frequency from scaling_cur_freq. cpuinfo_cur_freq reads it directly from hardware instead of the cached value.
(In reply to Viresh Kumar from comment #2) > You can read current frequency from scaling_cur_freq. cpuinfo_cur_freq reads > it directly from hardware instead of the cached value. scaling_cur_freq doesn't exist since intel_pstate is applied. scaling_cur_freq belongs to driver = acpi-cpufreq. I guess a patch is the best to think of.
(In reply to hg197 from comment #3) > scaling_cur_freq doesn't exist since intel_pstate is applied. > scaling_cur_freq belongs to driver = acpi-cpufreq. I guess a patch is the > best to think of. This is because intel_pstate doesn't implement a ->target() routine but setpolicy(). But for all other drivers with ->target or ->target_index(), it still exists.
Well, I hope Lan Tianyu's patch will tinker the issue.
/proc/cpuinfo also provides cpufreq which also comes from cpufreq_driver->get() the same as cpuinfo_cur_freq. Rafael wouldn't change the permission of cpuinfo_cur_freq. http://www.spinics.net/lists/cpufreq/msg08579.html Found a link about Dave Jones's answer about this. https://lkml.org/lkml/2004/8/25/244 So this will not be change.
*** Bug 111241 has been marked as a duplicate of this bug. ***