Re: question about one acpi-cpufreq commit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>
> > > 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...

good luck!

greg k-h



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux