Re: [Backport for linux-5.4.y PATCH 2/4] ARM: OMAP2+: Prepare timer code to backport dra7 timer wrap errata i940

[Greg KH]

On Wed, Jun 09, 2021 at 09:13:53AM +0300, Tony Lindgren wrote:
> Hi,
> 
> * Greg KH <greg@xxxxxxxxx> [210608 17:13]:
> > On Wed, Jun 02, 2021 at 01:46:23PM +0300, Tony Lindgren wrote:
> > > Prepare linux-5.4.y to backport upstream timer wrap errata commit
> > > 3efe7a878a11c13b5297057bfc1e5639ce1241ce and commit
> > > 25de4ce5ed02994aea8bc111d133308f6fd62566. Earlier kernels still use
> > > mach-omap2/timer instead of drivers/clocksource as these kernels still
> > > depend on legacy platform code for timers. Note that earlier stable
> > > kernels need also additional patches and will be posted separately.
> > 
> > I do not understand this paragraph.
> > 
> > What upstream commit is this?  And "posted separately" shouldn't show up
> > in a changelog text, right?
> 
> This would be a partial backport to add struct dmtimer_clockevent from
> commit 52762fbd1c4778ac9b173624ca0faacd22ef4724 to the platform timer
> code used in the older kernels.
> 
> How about the following for the description:
> 
> Upstream commit 52762fbd1c4778ac9b173624ca0faacd22ef4724 usage of
> struct dmtimer_clockevent backported to the platform timer code
> still used in linux-5.4.y stable kernel. Needed to backport upstream
> commit 3efe7a878a11c13b5297057bfc1e5639ce1241ce and commit
> 25de4ce5ed02994aea8bc111d133308f6fd62566. Earlier kernels use
> mach-omap2/timer instead of drivers/clocksource as these kernels still
> depend on legacy platform code for booting.

Why are you combining 2 commits into one here?

I do not understand what this commit really is at all still, sorry.

How about just providing backports for the individual commits, do not
combine them as that just is a mess.

> > Can you fix this up to make this obvious what is happening here and make
> > a patch series that I can take without editing changelog text?
> 
> Sure I'll repost the series, assuming the above is OK for description :)
> Please let me know if you need further details added.
> 
> Hmm so what's the correct way to prevent automatically applying these
> into the earlier stable kernels?

What would cause them to be automatically applied?  You need to let us
know what kernel(s) they should go to.

thanks,

greg k-h