Re: m68k using deprecated internal APIs?

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

 



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.walleij@xxxxxxxxxx>


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




[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux