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

[Tony Lindgren]

* Greg KH <greg@xxxxxxxxx> [210609 06:22]:
> On Wed, Jun 09, 2021 at 09:13:53AM +0300, Tony Lindgren wrote:
> > 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?

OK so still too confusing, how about let's just have:

Upstream commit 52762fbd1c4778ac9b173624ca0faacd22ef4724 usage of
struct dmtimer_clockevent backported to the platform timer code
still used in linux-5.4.y stable kernel.

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

It allows upstream fixes for drivers/clocksource/timer-ti-dm-systimer.c
to be backported to the legacy platform timer code in linux-5.4.y in
arch/arm/mach-omap2/timer.c.

We assume a single dmtimer clockevent instance only in linux-5.4.y
kernels, while for the dra7 hardware errata workaround we now need
extra percpu timers configured and need struct dmtimer_clockevent.

Backporting drivers/clocksource/timer-ti-dm-systimer.c directly seems
risky to me as linux-5.4.y still depends on legacy platform code for
booting and timers, including also the timer instances not used for
clocksource and clockevent. And it would be intrusive also for the
other SoCs not affected by the timer errata.

Of course the best option for folks using the stable kernels is to
move to the current long term kernel that already has the fixes for
drivers/clocksource/timer-ti-dm-systimer.c :)

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

OK

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

OK thanks, good to hear.

Regards,

Tony