force the compiler to use a valid register allocation for irq handlers

When we are calling the re-scheduling routine at the end of an irq
handling routine, we need to ensure that the high registers are not
currently saved on the system stack.
On Cortex-M3/M4, the compiler is normally doing tail-call optimization
there and behaving properly, but this fixes the fact that insanely large
interrupt handling routines where sometimes not compile and not running
properly (aka issue 24515).

This also prepares for one more core-specific DECLARE_IRQ routine on
Cortex-M0.

Note: now on, the IRQ handling routines should no longer be "static".

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BRANCH=none
BUG=chrome-os-partner:24515
TEST=make -j buildall
revert the workaround for 24515, see the issue happening only without
this CL.

Change-Id: Ic419369231925568df05815fd079ed191a5446db
Reviewed-on: https://chromium-review.googlesource.com/189153
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>

1 files changed, 1 insertions, 1 deletions

diff --git a/chip/lm4/hwtimer.c b/chip/lm4/hwtimer.c
index 088bd5713b..17d9c3e6ea 100644
--- a/chip/lm4/hwtimer.c
+++ b/chip/lm4/hwtimer.c
@@ -42,7 +42,7 @@ void __hw_clock_source_set(uint32_t ts)
 	LM4_TIMER_TAV(6) = 0xffffffff - ts;
 }
 
-static void __hw_clock_source_irq(void)
+void __hw_clock_source_irq(void)
 {
 	uint32_t status = LM4_TIMER_RIS(6);