Bug 65611

Summary:	wrong file mode of /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
Product:	Power Management	Reporter:	hg197
Component:	cpufreq	Assignee:	Lan Tianyu (tianyu.lan)
Status:	CLOSED DOCUMENTED
Severity:	normal	CC:	flux242, tianyu.lan, viresh.kumar
Priority:	P1
Hardware:	i386
OS:	Linux
Kernel Version:	3.12.1-1	Subsystem:
Regression:	No	Bisected commit-id:

Description hg197 2013-11-24 16:05:25 UTC

/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.

Comment 1 Lan Tianyu 2013-11-25 03:03:09 UTC

This also doesn't make sense to me. I will send a patch to change it and see other guys' comment.

Comment 2 Viresh Kumar 2013-11-25 04:41:47 UTC

You can read current frequency from scaling_cur_freq. cpuinfo_cur_freq reads it directly from hardware instead of the cached value.

Comment 3 hg197 2013-11-25 06:43:36 UTC

(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.

Comment 4 Viresh Kumar 2013-11-25 06:48:35 UTC

(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.

Comment 5 hg197 2013-11-25 07:00:03 UTC

Well, I hope Lan Tianyu's patch will tinker the issue.

Comment 6 Lan Tianyu 2013-11-28 01:36:40 UTC

/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.

Comment 7 Len Brown 2016-05-16 21:47:45 UTC

*** Bug 111241 has been marked as a duplicate of this bug. ***