[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAhV-H7wLp2EiEL0zyLL0_+tZAqTwy+tfFcyE9WwJeDYTfQY-g@mail.gmail.com>
Date: Wed, 24 Aug 2022 20:49:55 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Huacai Chen <chenhuacai@...ngson.cn>, loongarch@...ts.linux.dev,
Xuefeng Li <lixuefeng@...ngson.cn>,
Guo Ren <guoren@...nel.org>, Xuerui Wang <kernel@...0n.name>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
LKML <linux-kernel@...r.kernel.org>,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] LoongArch: Fix build warnings in VDSO
Hi, Arnd,
On Wed, Aug 24, 2022 at 6:10 PM Arnd Bergmann <arnd@...nel.org> wrote:
>
> On Sat, Aug 20, 2022 at 5:35 PM Huacai Chen <chenhuacai@...ngson.cn> wrote:
> >
> > diff --git a/arch/loongarch/vdso/vgetcpu.c b/arch/loongarch/vdso/vgetcpu.c
> > index 43a0078e4418..e02e775f5360 100644
> > --- a/arch/loongarch/vdso/vgetcpu.c
> > +++ b/arch/loongarch/vdso/vgetcpu.c
> > @@ -24,6 +24,8 @@ static __always_inline const struct vdso_pcpu_data *get_pcpu_data(void)
> > return (struct vdso_pcpu_data *)(get_vdso_base() - VDSO_DATA_SIZE);
> > }
> >
> > +extern
> > +int __vdso_getcpu(unsigned int *cpu, unsigned int *node, struct getcpu_cache *unused);
> > int __vdso_getcpu(unsigned int *cpu, unsigned int *node, struct getcpu_cache *unused)
> > {
>
> I don't think that adding the declaration before the function is a
> good workaround here,
> that is likely to just trigger another warning about declarations in .c files.
Yes, this is not a good solution, I just use the same method as RISC-V. :)
But "another warning" is a checkpatch warning, not a build warning, so
lkp@...el.com will not send bug reports again and again. :)
>
> I would add the declarations into a header file instead. If the
> prototypes are the same
> across architectures, this can be a global header that also avoids the
> warnings elsewhere,
> otherwise just keep it local to this directory.
gettimeofday, clock_gettime and clock_getres can be declared across
architectures, but getcpu seems not suitable because not all
architectures have it.
Huacai
>
> Arnd
Powered by blists - more mailing lists