[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160815231305.GE12212@joana>
Date: Mon, 15 Aug 2016 20:13:05 -0300
From: Gustavo Padovan <gustavo.padovan@...labora.com>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Sumit Semwal <sumit.semwal@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Luis de Bethencourt <luisbg@....samsung.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] include/linux: fix excess fence.h kernel-doc notation
2016-08-15 Randy Dunlap <rdunlap@...radead.org>:
> From: Randy Dunlap <rdunlap@...radead.org>
>
> Fix excess fields in kernel-doc notation in <linux/fence.h>
> after some struct fields were removed.
>
> Fixes these kernel-doc warnings:
> ..//include/linux/fence.h:85: warning: Excess struct/union/enum/typedef member 'child_list' description in 'fence'
> ..//include/linux/fence.h:85: warning: Excess struct/union/enum/typedef member 'active_list' description in 'fence'
>
> Fixes: 0431b9065f28 ("staging/android: bring struct sync_pt back")
>
> Cc: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
> Cc: Daniel Vetter <daniel.vetter@...ll.ch>
> Cc: Sumit Semwal <sumit.semwal@...aro.org>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: Luis de Bethencourt <luisbg@....samsung.com>
>
> Signed-off-by: Randy Dunlap <rdunlap@...radead.org>
> ---
> include/linux/fence.h | 2 --
> 1 file changed, 2 deletions(-)
>
> --- lnx-48-rc2.orig/include/linux/fence.h
> +++ lnx-48-rc2/include/linux/fence.h
> @@ -49,8 +49,6 @@ struct fence_cb;
> * @timestamp: Timestamp when the fence was signaled.
> * @status: Optional, only valid if < 0, must be set before calling
> * fence_signal, indicates that the fence has completed with an error.
> - * @child_list: list of children fences
> - * @active_list: list of active fences
> *
> * the flags member must be manipulated and read using the appropriate
> * atomic ops (bit_*), so taking the spinlock will not be needed most
Reviewed-by: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
Gustavo
Powered by blists - more mailing lists