linux-kernel - Re: [RFC 1/1] ARM: print MHz in /proc/cpuinfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAC3K-4rTMy4n0u1Lo5KQKMtGAeH1uE1St3D71YwPVYCJs4+U6g@mail.gmail.com>
Date:	Thu, 9 Jun 2016 13:36:42 -0400
From:	Jon Mason <jon.mason@...adcom.com>
To:	Sudeep Holla <sudeep.holla@....com>
Cc:	Russell King <linux@...linux.org.uk>, linux-kernel@...r.kernel.org,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC 1/1] ARM: print MHz in /proc/cpuinfo

On Thu, Jun 9, 2016 at 5:09 AM, Sudeep Holla <sudeep.holla@....com> wrote:
>
>
> On 08/06/16 20:31, Jon Mason wrote:
>>
>> On Wed, Jun 08, 2016 at 09:34:06AM +0100, Sudeep Holla wrote:
>>>
>>>
>>>
>>> On 07/06/16 22:08, Jon Mason wrote:
>>>>
>>>> Query the CPU core clock in the device tree to determine the core clock
>>>> speed.
>>>
>>>
>>> How do guarantee that it's the current frequency of the CPU ?
>>
>>
>> I am basing it on the assumption (perhaps incorrect) that the clock in
>> the CPU DT corresponds to the one determining the CPU clock rate.  And,
>> that this clock rate is accurate in describing the speed at which the
>> CPU is currently running.
>>
>
> As you already noticed, it's not always correct.
>
> [..]
>
>>>
>>> What if they just don't have in DT but have DVFS support ?
>>
>>
>> This can be extended to cover DVFS or SMC calls or anything else.
>> This was simply a first step to cover what appeared to be the most
>> prevalent case.
>>
>
> Using DVFS/CPUFreq makes this DT based approach irrelevant.
>
>>> Also whey do we need this support when the user-space can query the
>>> CPUFreq sysfs which is more accurate and maintains the current running
>>> frequency ?
>>
>>
>> This is exactly what x86 is doing to provide its value in
>> /proc/cpuinfo.  I could easily augment this patch to call
>> cpufreq_quick_get(), if it returns 0, then call clk_get_rate().  If
>> both return 0, then simply not print out anything (which would cover
>> all of the possibilities).  Or, I could have it just call
>> cpufreq_quick_get() to get the value.
>>
>
> Agree x86 has, may be for legacy reasons. It even has CPUFreq sysfs
> entries which is architecture agnostic while /proc/cpuinfo is more
> architecture based. So applications that want to be portable across
> architectures must choose the generic CPUFreq sysfs path rather than
> some x86 based cpuinfo.

Thank you for educating me.  I am taking this (and RMK's comment) as
any modification to add CPU speed to /proc/cpuinfo is not welcomed,
anyone who wants to query this should instead look at cpufreq in
sysfs, and any dev who wants to add such a thing should look into
writing a driver in drivers/cpufreq/.

Thanks,
Jon

>
> --
> Regards,
> Sudeep