On Wed, 14 Nov 2018, Linus Walleij wrote:
> > >
> > > You can see those patches here,
> > > https://github.com/fthain/linux/commits/mac68k-queue/
>
> This is looking very good. FWIW:
> Acked-by: Linus Walleij <linus.wall...@linaro.org>
>
Thanks for your review.
> Apart from this (which is the most important step!) I think the custom
> LED heartbeat code in kernel/time.c needs to be replaced with a standard
> drivers/leds driver for each LED using the "heartbeat" trigger as is
> custom these days.
>
> That should clean out another chunk of legacy time-related code.
>
Are you referring to LED heartbeat code in arch/m68k/kernel/time.c?
> I suppose you are currently keeping the call to timer_interrupt() for
> exactly this reason (i.e. keep the heartbeat LED blinking)?
>
It would be great to have that call inlined, which the compiler can't do
at the moment, because timer_interrupt() is in a different compilation
unit (arch/m68k/kernel/time.c).
Is there some other benefit to eliminating the call to timer_interrupt()
that I've overlooked?
> ...
> > Adding the timekeeping maintainers and Linus Walleij to Cc. Linus
> > worked on removing ARCH_USES_GETTIMEOFFSET on ARM several platforms in
> > the past.
> >
> > I noticed that the last timer rework involving
> > CONFIG_ARCH_USES_GETTIMEOFFSET was back in 2012 with commit
> > 7b1f62076bba ("time: convert arch_gettimeoffset to a pointer"). At the
> > time, we had cris, m32r, blackfin, m68k and lots of ARM platforms, now
> > it's only two StrongARM platforms (RPC and ARCH_EBSA110) and classic
> > m68k.
>
Adding the maintainer for those platforms to Cc...
> Believe it or not, I managed to procure both machines (RPC and EBSA110).
> Whether I can get them to boot Linux is still an open question.
>
> I suppose it would be possible to use a conversion strategy similar to
> Finn's and get rid of gettimeoffset altogether, if I could only test it
> on these boards.
>
I've dropped the ARM patch from my clocksource API patch series. As
Russell pointed out, it didn't actually fix the regression caused by
5cfc8ee0bb51.
I've also dropped the equivalent m68k patch, which was intended to address
4ad4c76b7afb. The best way to address that problem for -stable for m68k is
probably by backporting the clocksource API conversion.
Then there's the question of -stable fixes for the other architectures...
4f543fa41e78 alpha: convert to use arch_gettimeoffset()
95ad759c6b0f m32r: convert to use arch_gettimeoffset()
10f03f1a249d Blackfin: convert to use arch_gettimeoffset()
0299b1371d8f sparc: convert to arch_gettimeoffset()
ba875ba6b7cd cris: convert to use arch_gettimeoffset()
No doubt many of these have had a clocksource conversions already, and in
some cases even the oldest -stable branch may be unaffected because of
that. E.g.
9ce34c8f4466 Convert alpha to use clocksources instead of arch_gettimeoffset
--
> Yours.
> Linus Walleij
>
