linux-kernel - Re: [PATCH v5 03/12] PM / devfreq: Don't adjust to user limits in governors

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:   Fri, 03 Aug 2018 09:43:23 +0900
From:   Chanwoo Choi <cw00.choi@...sung.com>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     MyungJoo Ham <myungjoo.ham@...sung.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Brian Norris <briannorris@...omium.org>,
        Douglas Anderson <dianders@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Lee Jones <lee.jones@...aro.org>,
        Benson Leung <bleung@...omium.org>,
        Olof Johansson <olof@...om.net>
Subject: Re: [PATCH v5 03/12] PM / devfreq: Don't adjust to user limits in
 governors

Hi Matthias,

On 2018년 08월 03일 09:24, Matthias Kaehlcke wrote:
> On Fri, Aug 03, 2018 at 09:03:30AM +0900, Chanwoo Choi wrote:
>> Hi Matthias,
>>
>> On 2018년 08월 03일 08:36, Matthias Kaehlcke wrote:
>>> Hi Chanwoo,
>>>
>>> this patch and "PM / devfreq: Fix handling of min/max_freq == 0"
>>> address issues not directly related with the throttler. It seems it
>>> could still take a while for the throttler to move forward, do you
>>> want me to spin out these two patches so that they can get merged
>>> independently from the rest of the series?
>>
>> How about resend the devfreq patches(patch1/2/3/4/6) which don't depend on
>> throttler core with my reviewed tag? Maybe, it is easy to merge them through Myungjoo.
> 
> Sure, I can do this if you think it is reasonable to merge all these
> patches without the throttler.

IMO, patch1/2/3/6 looks good. I replied with my reviewed-tag for them.

patch4 defines the 'struct devfreq_policy' and then patch5
send notification with 'struct devfreq_policy' on original patch.
But, when we discussed it on patch5, new devfreq notification
send 'struct devfreq_freq_limits' better than 'struct devfreq_policy'.
So, patch4 would be required with more discussion. If myungjoo agree
the current patch4, I'm okay.

> 
> These are the patches we are talking about and my interpretation of
> their status:
> 
> [01] PM / devfreq: Init user limits from OPP limits, not viceversa
>   landed in Rafaels tree
> 
> [02] PM / devfreq: Fix handling of min/max_freq == 0
>   independent fix, can land
> 
> [03] PM / devfreq: Don't adjust to user limits in governors
>   independent improvement, can land
> 
> [04] PM / devfreq: Add struct devfreq_policy
>   edge case, can land if devfreq maintainers think that factoring out
>   some fields to the policy struct is an improvement independently of
>   the throttler
> 
> [05] PM / devfreq: Add support for policy notifiers
>   under heavy discussion ;-), can't land
> 
> [06] PM / devfreq: Make update_devfreq() public
>   has no user without the throttler, not sure if it should be merged
>   without it. up to devfreq maintainers.
> 
> Please let me know what you think

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics