Messages in this thread | | | Date | Mon, 8 Feb 2021 18:40:14 +0100 | From | Mauro Carvalho Chehab <> | Subject | Re: linux-next: build warning after merge of the v4l-dvb tree |
| |
Em Mon, 08 Feb 2021 13:57:56 -0300 Ezequiel Garcia <ezequiel@collabora.com> 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.
> > I guess fixing > > this properly could require changes to kerneldoc so I have no objections to > > the approach.
It is not a simple kernel-doc change.
The problem is that Kernel-doc expects:
/** * foo - something */ void foo(...)
As it parses the file lines sequentially, using the parameters at foo(...) to double-check if everything is ok.
In order for it to parse things like:
/** * foo - something */
... (some other functions in the middle) void foo(...)
Would require kernel-doc to first parse all the file, storing markups on a separate struct, and then, on a second step, produce an output.
Even if modified to do that, there's a question if the result would be what it is expected.
A separate thing would be to do things like:
/** * foo - something */ void __foo(...)
The problem here is that usually the arguments for __foo() are different than the ones for foo(). See for example the macros that have a __foo() functions with an owner argument, that are solved on a macro called foo().
Thanks, Mauro
| |