Re: question about one acpi-cpufreq commit

[Guoqing Jiang <guoqing.jiang@linux.dev>]

On 3/16/22 8:53 PM, Greg KH wrote:
> On Wed, Mar 16, 2022 at 08:42:56PM +0800, Guoqing Jiang wrote:
>>
>> On 3/16/22 7:02 PM, Greg KH wrote:
>>> On Wed, Mar 16, 2022 at 04:56:11PM +0800, Guoqing Jiang wrote:
>>>> Hi,
>>>>
>>>> I just found the commit in 5.10 stable kernel.
>>>>
>>>> stable-linux> git tag --sort=taggerdate --contain
>>>> 8a3fc32b322cc3081dd3569047c9834f496b4ab0 | head -1
>>>> v5.10.17
>>>>
>>>> commit 8a3fc32b322cc3081dd3569047c9834f496b4ab0
>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>> Date:   Thu Feb 4 18:25:37 2021 +0100
>>>>
>>>>       cpufreq: ACPI: Extend frequency tables to cover boost frequencies
>>>>
>>>>       commit 3c55e94c0adea4a5389c4b80f6ae9927dd6a4501 upstream.
>>>>
>>>>      [ ... ]
>>>>
>>>>       Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
>>>> systems")
>>>>       Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P
>>>> for frequency invariance on AMD EPYC")
>>>>       Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as
>>>> default with intel_pstate")
>>>>
>>>> Except db865272d9c4 was applied in v5.10-rc2, the others (41ea667227ba and
>>>> 976df7e5730e)
>>>> were first appeared in v5.11-rc1.
>>>>
>>>> linux> git tag --sort=taggerdate --contain 41ea667227ba | head -1
>>>> v5.11-rc1
>>>> linux> git tag --sort=taggerdate --contain 976df7e5730e | head -1
>>>> v5.11-rc1
>>>> linux> git tag --sort=taggerdate --contain db865272d9c4 | head -1
>>>> v5.10-rc2
>>>>
>>>> So I am wondering if the mentioned commit is suitable for 5.10 stable
>>>> kernel, or what am I missing?
>>> Is it causing a problem for you?  What is the issue with having it in
>>> the 5.10.y tree?
>> No.
>>
>> I am trying to port 41ea667227ba and relevant commits to our kernel which
>> is based on 5.10 stable kernel, and I am being asked to port 3c55e94c0ade
>> per the fix tag after 41ea667227ba was added, then I was confused because
>> of conflict.
> Don't "port" stable kernels, just do a normal merge and then all is much
> better.  That way you do not miss patches you should have applied but
> didn't realize until much later...

Thanks for the tip and also the effort for stable kernel maintenance!

Thanks,
Guoqing