linux-kernel - Re: [PATCH 0/8] cpufreq: Auto-register with energy model

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20210811053406.jqwextgtnxhgsjd2@vireshk-i7>
Date:   Wed, 11 Aug 2021 11:04:06 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Quentin Perret <qperret@...gle.com>
Cc:     Rafael Wysocki <rjw@...ysocki.net>,
        Vincent Donnefort <vincent.donnefort@....com>,
        lukasz.luba@....com, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Cristian Marussi <cristian.marussi@....com>,
        Fabio Estevam <festevam@...il.com>,
        Kevin Hilman <khilman@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        Sudeep Holla <sudeep.holla@....com>, linux-pm@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org, linux-omap@...r.kernel.org
Subject: Re: [PATCH 0/8] cpufreq: Auto-register with energy model

On 11-08-21, 10:48, Viresh Kumar wrote:
> On 10-08-21, 13:35, Quentin Perret wrote:
> > This series adds more code than it removes,
> 
> Sadly yes :(
> 
> > and the unregistration is
> > not a fix as we don't ever remove the EM tables by design, so not sure
> > either of these points are valid arguments.
> 
> I think that design needs to be looked over again, it looks broken to
> me everytime I land onto this code. I wonder why we don't unregister
> stuff.

Coming back to this series. We have two options, based on what I
proposed here:

https://lore.kernel.org/linux-pm/20210811050327.3yxrk4kqxjjwaztx@vireshk-i7/

1. Let cpufreq core register with EM on behalf of cpufreq drivers.

2. Update drivers to use ->ready() callback to do this stuff.

I am fine with both :)

-- 
viresh