[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <mhng-2a49da2a-fd67-4655-9302-3f44030b7863@palmer-mbp2014>
Date: Thu, 31 Mar 2022 16:03:17 -0700 (PDT)
From: Palmer Dabbelt <palmer@...belt.com>
To: rdunlap@...radead.org
CC: linux-kernel@...r.kernel.org, rdunlap@...radead.org, lkp@...el.com,
Atish Patra <atishp@...osinc.com>, anup@...infault.org,
Paul Walmsley <paul.walmsley@...ive.com>,
aou@...s.berkeley.edu, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH] riscv: cpu.c: don't use kernel-doc markers for comments
On Mon, 28 Mar 2022 15:04:17 PDT (-0700), rdunlap@...radead.org wrote:
> Repair kernel-doc build warnings caused by using "/**" kernel-doc
> markers for comments that are not in kernel-doc format:
>
> cpu.c:89: warning: cannot understand function prototype: 'struct riscv_isa_ext_data isa_ext_arr[] = '
> cpu.c:114: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
>
> Signed-off-by: Randy Dunlap <rdunlap@...radead.org>
> Reported-by: kernel test robot <lkp@...el.com>
> Cc: Atish Patra <atishp@...osinc.com>
> Cc: Palmer Dabbelt <palmer@...osinc.com>
> Cc: Anup Patel <anup@...infault.org>
> Cc: Paul Walmsley <paul.walmsley@...ive.com>
> Cc: Palmer Dabbelt <palmer@...belt.com>
> Cc: Albert Ou <aou@...s.berkeley.edu>
> Cc: linux-riscv@...ts.infradead.org
> ---
> arch/riscv/kernel/cpu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20220328.orig/arch/riscv/kernel/cpu.c
> +++ linux-next-20220328/arch/riscv/kernel/cpu.c
> @@ -69,7 +69,7 @@ int riscv_of_parent_hartid(struct device
> .uprop = #UPROP, \
> .isa_ext_id = EXTID, \
> }
> -/**
> +/*
> * Here are the ordering rules of extension naming defined by RISC-V
> * specification :
> * 1. All extensions should be separated from other multi-letter extensions
> @@ -110,7 +110,7 @@ static void print_isa_ext(struct seq_fil
> }
> }
>
> -/**
> +/*
> * These are the only valid base (single letter) ISA extensions as per the spec.
> * It also specifies the canonical order in which it appears in the spec.
> * Some of the extension may just be a place holder for now (B, K, P, J).
Thanks, this is on for-next (still for this merge window for me).
Powered by blists - more mailing lists