linux-kernel - Re: [PATCH] powerpc/eeh_cache: fix a W=1 kernel-doc warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1561665339.5154.92.camel@lca.pw>
Date:   Thu, 27 Jun 2019 15:55:39 -0400
From:   Qian Cai <cai@....pw>
To:     mpe@...erman.id.au
Cc:     ruscur@...sell.cc, sbobroff@...ux.ibm.com, oohall@...il.com,
        benh@...nel.crashing.org, paulus@...ba.org,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] powerpc/eeh_cache: fix a W=1 kernel-doc warning

Ping.

On Wed, 2019-06-05 at 16:46 -0400, Qian Cai wrote:
> The opening comment mark "/**" is reserved for kernel-doc comments, so
> it will generate a warning with "make W=1".
> 
> arch/powerpc/kernel/eeh_cache.c:37: warning: cannot understand function
> prototype: 'struct pci_io_addr_range
> 
> Since this is not a kernel-doc for the struct below, but rather an
> overview of this source eeh_cache.c, just use the free-form comments
> kernel-doc syntax instead.
> 
> Signed-off-by: Qian Cai <cai@....pw>
> ---
>  arch/powerpc/kernel/eeh_cache.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/eeh_cache.c b/arch/powerpc/kernel/eeh_cache.c
> index 320472373122..05ffd32b3416 100644
> --- a/arch/powerpc/kernel/eeh_cache.c
> +++ b/arch/powerpc/kernel/eeh_cache.c
> @@ -18,6 +18,8 @@
>  
>  
>  /**
> + * DOC: Overview
> + *
>   * The pci address cache subsystem.  This subsystem places
>   * PCI device address resources into a red-black tree, sorted
>   * according to the address range, so that given only an i/o
> @@ -34,6 +36,7 @@
>   * than any hash algo I could think of for this problem, even
>   * with the penalty of slow pointer chases for d-cache misses).
>   */
> +
>  struct pci_io_addr_range {
>  	struct rb_node rb_node;
>  	resource_size_t addr_lo;