Dear,
在 2021/3/24 6:18, Alexandre Belloni 写道:
Hello,
On 23/03/2021 05:12:57-0400, He Ying wrote:
We found these warnings in arch/powerpc/kernel/time.c as follows:
warning: symbol 'decrementer_max' was not declared. Should it be static?
warning: symbol 'rtc_lock' was not declared. Should it be static?
warning: symbol 'dtl_consumer' was not declared. Should it be static?
Declare 'decrementer_max' and 'rtc_lock' in powerpc asm/time.h.
Rename 'rtc_lock' in drviers/rtc/rtc-vr41xx.c to 'vr41xx_rtc_lock' to
avoid the conflict with the variable in powerpc asm/time.h.
Move 'dtl_consumer' definition behind "include <asm/dtl.h>" because it
is declared there.
Reported-by: Hulk Robot <hulkci@xxxxxxxxxx>
Signed-off-by: He Ying <heying24@xxxxxxxxxx>
---
v2:
- Instead of including linux/mc146818rtc.h in powerpc kernel/time.c, declare
rtc_lock in powerpc asm/time.h.
V1 was actually the correct thing to do. rtc_lock is there exactly
because chrp and maple are using mc146818 compatible RTCs. This is then
useful because then drivers/char/nvram.c is enabled. The proper fix
would be to scrap all of that and use rtc-cmos for those platforms as
this drives the RTC properly and exposes the NVRAM for the mc146818.
Do you mean that 'rtc_lock' declared in linux/mc146818rtc.h points to
same thing as that defined in powerpc kernel/time.c? And you think V1
was correct? Oh, I should have added you to my patch V1 senders:)
Or at least, if there are no users for the char/nvram driver on those
two platforms, remove the spinlock and stop enabling CONFIG_NVRAM or
more likely rename the symbol as it seems to be abused by both chrp and
powermac.
I'm not completely against the rename in vr41xxx but the fix for the
warnings can and should be contained in arch/powerpc.
Yes, I agree with you. But I have no choice because there is a compiling
error.
Maybe there's a better way.
So, what about my patch V1? Should I resend it and add you to senders?
Thanks.
