linux-kernel - Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning

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]

Date:   Tue, 6 Oct 2020 00:24:01 +0530
From:   Sumit Gupta <sumitg@...dia.com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
CC:     <rjw@...ysocki.net>, <thierry.reding@...il.com>,
        <jonathanh@...dia.com>, <linux-pm@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <ksitaraman@...dia.com>,
        <bbasu@...dia.com>, Sumit Gupta <sumitg@...dia.com>
Subject: Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning


>> Warning coming during boot because the boot freq set by bootloader
>> gets filtered out due to big freq steps while creating freq_table.
>> Fixing this by setting closest ndiv value from freq_table.
>> Warning:
>>    cpufreq: cpufreq_online: CPU0: Running at unlisted freq
>>    cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed
>>
>> Also, added change in init to wait till current frequency becomes
>> equal or near to the previously requested frequency. This is done
>> because it takes some time to restore the previous frequency while
>> turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
> 
> So you are trying to figure if the frequency is listed in freq-table or not,
> otherwise setting the frequency to a value you think is appropriate. Right ?
During boot, want to set the frequency from freq_table which is closest 
to the one set by bootloader.
During resume from suspend-to-idle, want to restore the frequency which 
was set on non-boot cores before they were hotplug powered off.

> 
> This is what the cpufreq core already does when it printed these boot time
> messages. Do we really need to add this much code in here ?
We want to avoid the warning messages.

> 
> If you really don't want to see the warning, how about fixing it the way cpufreq
> core does ? i.e. with this call:
> 
> ret = __cpufreq_driver_target(policy, policy->cur - 1, CPUFREQ_RELATION_L);
> 
The cpufreq core change will help in bootup case but not during the case 
of resume.
In this change, reading the previously stored value and restoring it 
will also fix the warning message during resume.


> --
> viresh
>