linux-kernel - Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support

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>] [day] [month] [year] [list]

Message-id: <20161124061416epcms1p44a0152bca14312f1229cab835ea0297f@epcms1p4>
Date:   Thu, 24 Nov 2016 06:14:16 +0000
From:   MyungJoo Ham <myungjoo.ham@...sung.com>
To:     hl@...k-chips.com <hl@...k-chips.com>
Cc:     Chanwoo Choi <cw00.choi@...sung.com>,
        dianders@...omium.org <dianders@...omium.org>,
        linux-rockchip@...ts.infradead.org 
        <linux-rockchip@...ts.infradead.org>,
        linux-pm@...r.kernel.org 
        <linux-pm@...r.kernel.org>,
        dbasehore@...omium.org 
        <dbasehore@...omium.org>,
        linux-arm-kernel@...ts.infradead.org 
        <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel@...r.kernel.org 
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support

On Thu, Nov 24, 2016 at 11:18 AM, hl <hl@...k-chips.com> wrote:
> Hi MyungJoo Ham,
[]
>>
>> We still need to sync the all status even i call target() in
>> devfreq_suspend/resume_device
>> directly, so still need update_devfreq() other setp except
>> devfreq->governor->get_target_freq(devfreq, &freq);
>
> And i think it better to be governor behaviors, for userspace they may not
> want to change
> the suspend frequency like other governor, the frequency should decide by
> the user, if they
> want this function, they should like other governor to rigister a
> devfreq_monitor_suspend().


> What do you think about my rev6 patch?

If I understand the intention correctly, this is for the stability of
the device due to the behavior or bootloader/SoC-initializer, which
has nothing to do with governors.

Even if users are using userspace, as long as they set the custom
frequencies lower than the default, they have the possibility of
being unstable as ondemand is going to have.


To reuse the update_devfreq() code, you may do something like:

static int _update_freq(struct devfreq *devfreq, bool is_suspending)
{
    /* original contents of update_freq with if statement with is_suspending wrapping get_target_freq */
}
int update_freq(struct devfreq *devfreq)
{
	return _update_freq(devfreq, false);
}


There should be other good non-invasive methods that are not governoe-specific as well.



Cheers,
MyungJoo