[U-Boot] [PATCH v3] AVR32: fix timer_init() function
timer_init() now returns an int (the error code) instead of void. This makes compilation fail with:
interrupts.c:111: error: conflicting types for 'timer_init' /home/svens/u-boot/u-boot/include/common.h:246: error: previous declaration of 'timer_init' was here make[1]: *** [interrupts.o] Error 1
Signed-off-by: Sven Schnelle svens@stackframe.org --- Changes for v3: - return -EINVAL regardless of the return value Changes for v2: - Coding style
arch/avr32/cpu/interrupts.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/avr32/cpu/interrupts.c b/arch/avr32/cpu/interrupts.c index 6681e13..49a00f1 100644 --- a/arch/avr32/cpu/interrupts.c +++ b/arch/avr32/cpu/interrupts.c @@ -107,7 +107,7 @@ static int set_interrupt_handler(unsigned int nr, void (*handler)(void), return 0; }
-void timer_init(void) +int timer_init(void) { extern void timer_interrupt_handler(void); u64 tmp; @@ -120,8 +120,9 @@ void timer_init(void) tb_factor = (u32)tmp;
if (set_interrupt_handler(0, &timer_interrupt_handler, 3)) - return; + return -EINVAL;
/* For all practical purposes, this gives us an overflow interrupt */ sysreg_write(COMPARE, 0xffffffff); + return 0; } -- 1.7.5.4
Dear Sven,
Am 04.10.2015 21:53, schrieb Sven Schnelle:
timer_init() now returns an int (the error code) instead of void. This makes compilation fail with:
interrupts.c:111: error: conflicting types for 'timer_init' /home/svens/u-boot/u-boot/include/common.h:246: error: previous declaration of 'timer_init' was here make[1]: *** [interrupts.o] Error 1
Signed-off-by: Sven Schnelle svens@stackframe.org
Acked-by: Andreas Bießmann andreas.devel@googlemail.com
Hi Wolfgang,
Le 05/10/2011 09:12, Andreas Bießmann a écrit :
Dear Sven,
Am 04.10.2015 21:53, schrieb Sven Schnelle:
Apparently, something went quite wrong with the date for this patch. See http://patchwork.ozlabs.org/patch/117688/, which places it in 2015 (like Andreas' answer does), ignoring Sven's patch mails dates.
Wolfgang, maybe this should be mentioned to the patchwork folks.
Amicalement,
Dear Albert,
Am 08.11.2011 10:38, schrieb Albert ARIBAUD:
Hi Wolfgang,
Le 05/10/2011 09:12, Andreas Bießmann a écrit :
Dear Sven,
Am 04.10.2015 21:53, schrieb Sven Schnelle:
Apparently, something went quite wrong with the date for this patch. See http://patchwork.ozlabs.org/patch/117688/, which places it in 2015 (like Andreas' answer does), ignoring Sven's patch mails dates.
Sven's MUA has set the 'Date:' field to 'Date: Sun, 4 Oct 2015 21:53:32 +0200' in Mail header.
BTW this will also be the date of the patch in git and could lead to problems when merge/rebase in future. Sven, could you please provide another version of the patch _or_ Reinhard could you please adopt the mail header (Date:) before applying this patch?
Wolfgang, maybe this should be mentioned to the patchwork folks.
I don't think patchwork was wrong here. My MUA acts the same way.
best regards
Andreas Bießmann
On Sun, 4 Oct 2015 21:53:32 +0200 Sven Schnelle svens@stackframe.org wrote:
timer_init() now returns an int (the error code) instead of void. This makes compilation fail with:
interrupts.c:111: error: conflicting types for 'timer_init' /home/svens/u-boot/u-boot/include/common.h:246: error: previous declaration of 'timer_init' was here make[1]: *** [interrupts.o] Error 1
Signed-off-by: Sven Schnelle svens@stackframe.org
Changes for v3:
- return -EINVAL regardless of the return value
Changes for v2:
- Coding style
arch/avr32/cpu/interrupts.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
Applied to u-boot-staging/agust@denx.de after fixing the date to patch reception date from email header. Thanks.
Anatolij
Dear Sven Schnelle,
In message 1443988412-13421-1-git-send-email-svens@stackframe.org you wrote:
timer_init() now returns an int (the error code) instead of void. This makes compilation fail with:
interrupts.c:111: error: conflicting types for 'timer_init' /home/svens/u-boot/u-boot/include/common.h:246: error: previous declaration of 'timer_init' was here make[1]: *** [interrupts.o] Error 1
Signed-off-by: Sven Schnelle svens@stackframe.org
Changes for v3:
- return -EINVAL regardless of the return value
Changes for v2:
- Coding style
arch/avr32/cpu/interrupts.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
Applied, thanks. [Cherry-picked Anatolij's commit.]
Best regards,
Wolfgang Denk
Dear Sven,
Date: Sun, 4 Oct 2015 21:53:32 +0200
would you be willing to disclose the secrets of running such a time machine ?
In message 1443988412-13421-1-git-send-email-svens@stackframe.org you wrote:
timer_init() now returns an int (the error code) instead of void. This makes compilation fail with:
interrupts.c:111: error: conflicting types for 'timer_init' /home/svens/u-boot/u-boot/include/common.h:246: error: previous declaration of 'timer_init' was here make[1]: *** [interrupts.o] Error 1
We're just discussing to drop support for AVR32 systems due to lack of a custodian, and appearent lack of interest, see 02/25 To:u-boot@lists.d [PATCH] AVR32 removal due to lack of custodian. http://article.gmane.org/gmane.comp.boot-loaders.u-boot/125752
Are you still interestedin AVR32? Would you be willing to volunteer to take over custodianship for this processor family?
Or Andreas, would you?
Best regards,
Wolfgang Denk
Hi Wolfgang,
On 02/26/2012 11:40 PM, Wolfgang Denk wrote:
Dear Sven,
Date: Sun, 4 Oct 2015 21:53:32 +0200
would you be willing to disclose the secrets of running such a time machine ?
Hehe. The 'time machine' was basically a dead CMOS battery in my Thinkpad at that time ;)
In message1443988412-13421-1-git-send-email-svens@stackframe.org you wrote:
timer_init() now returns an int (the error code) instead of void. This makes compilation fail with:
interrupts.c:111: error: conflicting types for 'timer_init' /home/svens/u-boot/u-boot/include/common.h:246: error: previous declaration of 'timer_init' was here make[1]: *** [interrupts.o] Error 1
We're just discussing to drop support for AVR32 systems due to lack of a custodian, and appearent lack of interest, see 02/25 To:u-boot@lists.d [PATCH] AVR32 removal due to lack of custodian. http://article.gmane.org/gmane.comp.boot-loaders.u-boot/125752
Are you still interestedin AVR32? Would you be willing to volunteer to take over custodianship for this processor family?
I fear i don't have enough time for maintaining a port, and i only have one AVR32 Board (the ATGNW100). I think Andreas would be a much better maintainer, IMHO he has much more knowledge on the AVR32 area.
Regards, Sven
participants (5)
-
Albert ARIBAUD -
Anatolij Gustschin -
Andreas Bießmann -
Sven Schnelle -
Wolfgang Denk