linux-kernel - Re: [PATCH 1/2] thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq

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: <27df4e4f-b6d7-9a58-f2dd-d6afa748e217@arm.com>
Date:   Tue, 22 Feb 2022 18:31:55 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     amit.kachhap@...il.com, viresh.kumar@...aro.org, rafael@...nel.org,
        amitk@...nel.org, rui.zhang@...el.com, dietmar.eggemann@....com,
        Pierre.Gondois@....com, Matthias Kaehlcke <mka@...omium.org>,
        Doug Anderson <dianders@...omium.org>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] thermal: cooling: Check Energy Model type in
 cpufreq_cooling and devfreq_cooling



On 2/22/22 18:12, Daniel Lezcano wrote:
> 
> Hi Lukasz,
> 
> I don't think it makes sense to remove the support of the energy model 
> if the units are abstracts.
> 
> IIUC, regarding your previous answer, we don't really know what will do 
> the SoC vendor with these numbers and likely they will provide 
> consistent abstract values which won't prevent a correct behavior.
> 
> What would be the benefit of giving inconsistent abstract values which 
> will be unusable except of giving a broken energy model?

The power values in the EM which has abstract scale, would make sense to 
EAS, but not for IPA or DTPM. Those platforms which want to enable EAS,
but don't need IPA, would register such '<a_good_name_here>' EM.

> 
> Your proposed changes would be acceptable if the energy model has a 
> broken flag IMO

That is doable. I can add that flag, so we can call it 'artificial' EM
(when this new flag is set).

Let me craft the RFC patch with this new flag proposal then.
Do you agree? Can I also add you as 'Suggested-by'?

Thank you for coming back to me with the comments.