From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A363C433E9 for ; Mon, 8 Feb 2021 18:54:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E088D64E5A for ; Mon, 8 Feb 2021 18:54:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234689AbhBHSyC (ORCPT ); Mon, 8 Feb 2021 13:54:02 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:39764 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233805AbhBHSxx (ORCPT ); Mon, 8 Feb 2021 13:53:53 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 881841F44B0B Message-ID: Subject: Re: linux-next: build warning after merge of the v4l-dvb tree From: Ezequiel Garcia To: Mauro Carvalho Chehab Cc: Sakari Ailus , Stephen Rothwell , Linux Kernel Mailing List , Linux Next Mailing List Date: Mon, 08 Feb 2021 15:53:00 -0300 In-Reply-To: <20210208184014.55128fb5@coco.lan> References: <20210208233716.16d962ad@canb.auug.org.au> <56cd99bbf526b43507579b5775bac5f885319866.camel@collabora.com> <20210208164618.GY32460@paasikivi.fi.intel.com> <4af499f5931d6b04a42787ae17525c63247573e6.camel@collabora.com> <20210208184014.55128fb5@coco.lan> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.2-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-next@vger.kernel.org On Mon, 2021-02-08 at 18:40 +0100, Mauro Carvalho Chehab wrote: > Em Mon, 08 Feb 2021 13:57:56 -0300 > Ezequiel Garcia escreveu: > > > On Mon, 2021-02-08 at 18:46 +0200, Sakari Ailus wrote: > > > Hi Ezequiel, > > > > > > Thanks for addressing this. > > > > > > On Mon, Feb 08, 2021 at 01:42:21PM -0300, Ezequiel Garcia wrote:  > > > > Hi Stephen, > > > > > > > > On Mon, 2021-02-08 at 23:37 +1100, Stephen Rothwell wrote:  > > > > > Hi all, > > > > > > > > > > After merging the v4l-dvb tree, today's linux-next build (htmldocs) > > > > > produced this warning: > > > > > > > > > > include/media/v4l2-async.h:178: warning: expecting prototype for v4l2_async_notifier_add_fwnode_subdev(). Prototype was for > > > > > __v4l2_async_notifier_add_fwnode_subdev() instead > > > > > include/media/v4l2-async.h:207: warning: expecting prototype for v4l2_async_notifier_add_fwnode_remote_subdev(). Prototype was for > > > > > __v4l2_async_notifier_add_fwnode_remote_subdev() instead > > > > > include/media/v4l2-async.h:230: warning: expecting prototype for v4l2_async_notifier_add_i2c_subdev(). Prototype was for > > > > > __v4l2_async_notifier_add_i2c_subdev() instead > > > > > > > > > > Maybe introduced by commit > > > > > > > > > >   c1cc23625062 ("media: v4l2-async: Discourage use of v4l2_async_notifier_add_subdev") > > > > >   > > > > > > > > Thanks for spotting this. Should be fixed by: > > > > > > > > diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h > > > > index 6f22daa6f067..3785445282fc 100644 > > > > --- a/include/media/v4l2-async.h > > > > +++ b/include/media/v4l2-async.h > > > > @@ -157,7 +157,7 @@ int __v4l2_async_notifier_add_subdev(struct v4l2_async_notifier *notifier, > > > >                                    struct v4l2_async_subdev *asd); > > > >   > > > >  /** > > > > - * v4l2_async_notifier_add_fwnode_subdev - Allocate and add a fwnode async > > > > + * __v4l2_async_notifier_add_fwnode_subdev - Allocate and add a fwnode async  > > > > > > The problem with the approach is that this no longer documents the API that > > > drivers are intended to use, but the intermediate one. > > Yep. the better would be to keep documenting what will be used. > Is there a way to silence/ignore the warning for a specific function(s)? Ezequiel