[PATCH] arm64: vdso: fix "no previous prototype" warning

[Vincenzo Frascino]

Hi Marc,

On 1/22/22 12:05 PM, Marc Kleine-Budde wrote:
> On 21.01.2022 12:12:26, Vincenzo Frascino wrote:
>> Hi Marc,
>>
>> On 1/9/22 11:35 AM, Marc Kleine-Budde wrote:
>>> If compiling the arm64 kernel with W=1 the following warning is produced:
>>>
>>> | arch/arm64/kernel/vdso/vgettimeofday.c:9:5: error: no previous prototype for ‘__kernel_clock_gettime’ [-Werror=missing-prototypes]
>>> |     9 | int __kernel_clock_gettime(clockid_t clock,
>>> |       |     ^~~~~~~~~~~~~~~~~~~~~~
>>> | arch/arm64/kernel/vdso/vgettimeofday.c:15:5: error: no previous prototype for ‘__kernel_gettimeofday’ [-Werror=missing-prototypes]
>>> |    15 | int __kernel_gettimeofday(struct __kernel_old_timeval *tv,
>>> |       |     ^~~~~~~~~~~~~~~~~~~~~
>>> | arch/arm64/kernel/vdso/vgettimeofday.c:21:5: error: no previous prototype for ‘__kernel_clock_getres’ [-Werror=missing-prototypes]
>>> |    21 | int __kernel_clock_getres(clockid_t clock_id,
>>> |       |     ^~~~~~~~~~~~~~~~~~~~~
>>>
>>> This patch adds the missing prototype to fix the warning and make
>>> compilation with "CONFIG_WERROR=y" possible.
>>>
>>
>> Instead of adding the prototypes, how about we silence the warning for the
>> specific file? Since adding them does not seem to add any value in this context.
>>
>> If you agree, could please test the patch I sent in reply to this one and let me
>> know if it works for your usecase? Thanks.
> 
> The patch silences the W=1 warning, sparse (C=1) however still
> complains:
> 
> | arch/arm64/kernel/vdso/vgettimeofday.c:9:5: warning: symbol '__kernel_clock_gettime' was not declared. Should it be static?
> | arch/arm64/kernel/vdso/vgettimeofday.c:15:5: warning: symbol '__kernel_gettimeofday' was not declared. Should it be static?
> | arch/arm64/kernel/vdso/vgettimeofday.c:21:5: warning: symbol '__kernel_clock_getres' was not declared. Should it be static?
> 

I had a look this morning but it seems but it seems that CHECKFLAGS does not
allow to ignore warnings. I need to investigate it further, but in the meantime
I propose to go ahead with the other patch since it addresses a compilation issue.


> regards,
> Marc
> 

-- 
Regards,
Vincenzo