25 Feb, 2018
1 commit
-
[ Upstream commit e814bccbafece52a24e152d2395b5d49eef55841 ]
My bisect scripts starting running into build failures when trying to
compile 4.15-rc1 with the builds failing with things like:drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!
The line in question is actually just a #define, but after some digging
it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea
("Add optional check for bad kernel-doc comments") that results in
kernel-doc running on each source file. The file in question has a
badly formatted comment immediately before the #define:/**
* struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
* bus layer usage.
*/which causes the regex in dump_struct to fail (lack of braces following
struct declaration) and kernel-doc returns 1, which causes the build
to fail.Fix the issue by always returning 0 from kernel-doc when invoked with
-none. It successfully generates no documentation, and prints out any
issues.Cc: Matthew Wilcox
Cc: Jonathan Corbet
Signed-off-by: Will Deacon
Signed-off-by: Jonathan Corbet
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
22 Feb, 2018
1 commit
-
commit 4675ff05de2d76d167336b368bd07f3fef6ed5a6 upstream.
Fix up makefiles, remove references, and git rm kmemcheck.
Link: http://lkml.kernel.org/r/20171007030159.22241-4-alexander.levin@verizon.com
Signed-off-by: Sasha Levin
Cc: Steven Rostedt
Cc: Vegard Nossum
Cc: Pekka Enberg
Cc: Michal Hocko
Cc: Eric W. Biederman
Cc: Alexander Potapenko
Cc: Tim Hansen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
31 Aug, 2017
1 commit
-
Reported by Johannes Berg [1]. Problem here: function
process_proto_type() concatenates the striped lines of declaration
without any whitespace. A one-liner of::struct something {
struct foo
bar;
};has to be::
struct something {struct foo bar;};
Without the patching process_proto_type(), the result missed the space
between 'foo' and 'bar'::struct something {struct foobar;};
Bugfix of process_proto_type() brings next error when blank lines
between enum declaration::warning: Enum value ' ' not described in enum 'foo'
Problem here: dump_enum() does not strip leading whitespaces from
the concatenated string (with the new additional space from
process_proto_type).[1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg12410.html
Signed-off-by: Markus Heiser
Signed-off-by: Jonathan Corbet
08 Jul, 2017
1 commit
-
…asahiroy/linux-kbuild
Pull misc Kbuild updates from Masahiro Yamada:
- Use more portable shebang for Perl scripts
- Remove trailing spaces from GCC version in kernel log
- Make initramfs generation deterministic
* tag 'kbuild-misc-v4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kbuild: create deterministic initramfs directory listings
scripts/mkcompile_h: Remove trailing spaces from compiler version
scripts: Switch to more portable Perl shebang
03 Jul, 2017
1 commit
-
DECLARE_HASHTABLE needs similar handling to DECLARE_BITMAP
because otherwise kernel-doc assumes the member name is the
second, not first macro parameter.Signed-off-by: Jakub Kicinski
Signed-off-by: Jonathan Corbet
14 May, 2017
1 commit
-
The default NetBSD package manager is pkgsrc and it installs Perl
along other third party programs under custom and configurable prefix.
The default prefix for binary prebuilt packages is /usr/pkg, and the
Perl executable lands in /usr/pkg/bin/perl.This change switches "/usr/bin/perl" to "/usr/bin/env perl" as it's
the most portable solution that should work for almost everybody.
Perl's executable is detected automatically.This change switches -w option passed to the executable with more
modern "use warnings;" approach. There is no functional change to the
default behavior.While there, drop "require 5" from scripts/namespace.pl (Perl from 1994?).
Signed-off-by: Kamil Rytarowski
Signed-off-by: Masahiro Yamada
03 Apr, 2017
2 commits
-
lib/crc32c defines one parameter as:
const u32 (*tab)[256]Better handle parenthesis, to avoid those warnings:
./lib/crc32.c:149: warning: No description found for parameter 'tab)[256]'
./lib/crc32.c:149: warning: Excess function parameter 'tab' description in 'crc32_le_generic'
./lib/crc32.c:294: warning: No description found for parameter 'tab)[256]'
./lib/crc32.c:294: warning: Excess function parameter 'tab' description in 'crc32_be_generic'Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jonathan Corbet -
On ReST, adding a text like ``literal`` is valid. However,
the kernel-doc script won't handle it fine.We really need this feature, in order to escape things like
%ph, with is found on some C files.Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jonathan Corbet
27 Jan, 2017
1 commit
-
Clearly nobody ever tried to build the documentation for the radix tree
before:include/linux/radix-tree.h:400: warning: cannot understand function
prototype: 'void ** radix_tree_iter_init(struct radix_tree_iter *iter,
unsigned long start) 'Indeed, the regexes only handled a single '*', not one-or-more. I have
tried to fix that, but now I have perl regexes all over my hands, and
I fear I shall never be clean again.Signed-off-by: Matthew Wilcox
Signed-off-by: Jonathan Corbet
14 Jan, 2017
1 commit
-
Documentation for array parameters passed in a function, like the first
argument in the function below, weren't getting exported in the rst
format, although they work fine for html and pdf formats:void drm_clflush_pages(struct page * pages[], unsigned long num_pages)
That's because the string key to store the description in the
parameterdescs dictionary doesn't have the [] suffix. This cleans up
the suffix from the key before accessing the dictionary.Signed-off-by: Gabriel Krisman Bertazi
Fixes: c0d1b6ee780a ("kernel-doc: produce RestructuredText output")
Reviewed-by: Jani Nikula
Signed-off-by: Jonathan Corbet
05 Jan, 2017
5 commits
-
$type_struct_full and friends are only used by the restructuredText
backend, because it needs to separate enum/struct/typedef/union from
the name of the type. However, $type_struct is *also* used by the rST
backend. This is confusing.This patch replaces $type_struct's use in the rST backend with a new
$type_fallback; it modifies $type_struct so that it can be used in the
rST backend; and creates regular expressions like $type_struct
for enum/typedef/union, for use in all backends.Note that, compared to $type_*_full, in the new regexes $1 includes both
the "kind" and the name (before, $1 was pretty much a constant).Signed-off-by: Paolo Bonzini
Acked-by: Jani Nikula
Signed-off-by: Jonathan Corbet -
Note that, in order to produce the correct Docbook markup, the "." or "->"
must be separated from the member name in the regex's captured fields. For
consistency, this change is applied to $type_member and $type_member_func
too, not just to $type_member_xml.List mode only prints the struct name, to avoid any undesired change in
the operation of docproc.Signed-off-by: Paolo Bonzini
Acked-by: Jani Nikula
Signed-off-by: Jonathan Corbet -
The restructuredText output includes both the parameter type and
the name for functions and function-typed members. Do the same
for docbook.Signed-off-by: Paolo Bonzini
Acked-by: Jani Nikula
Signed-off-by: Jonathan Corbet -
An inline function can have an attribute, as in include/linux/log2.h,
and kernel-doc handles this already for simple cases. However,
some attributes have arguments (e.g. the "target" attribute).
Handle those too.Furthermore, attributes could be at the beginning of a function
declaration, before the return type. To correctly handle this case,
you need to strip spaces after the attributes; otherwise, dump_function
is left confused.Signed-off-by: Paolo Bonzini
Acked-by: Jani Nikula
Signed-off-by: Jonathan Corbet -
A prototype like
/**
* foo - sample definition
* @bar: a parameter
*/
int foo(int (*bar)(int x,
int y));is currently producing
.. c:function:: int foo (int (*bar) (int x, int y)
sample definition
**Parameters**
``int (*)(int x, int y) bar``
a parameterCollapse the spaces so that the output is nicer.
Signed-off-by: Paolo Bonzini
Acked-by: Jani Nikula
Signed-off-by: Jonathan Corbet
17 Nov, 2016
1 commit
-
kernel-doc supports documenting struct members "inline" since
a4c6ebede2f9 ("scripts/kernel-doc Allow struct arguments documentation
in struct body"). This requires the inline kernel-doc comments to have
the opening and closing comment markers (/** and */ respectively) on
lines of their own, even for short comments. For example:/**
* struct foo - struct documentation
*/
struct foo {
/**
* @bar: member documentation
*/
int bar;
};Add support for one line inline comments:
/**
* struct foo - struct documentation
*/
struct foo {
/** @bar: member documentation */
int bar;
};Note that mixing of the two in one doc comment is not allowed; either
both comment markers must be on lines of their own, or both must be on
the one line. This limitation keeps both the comments more uniform, and
kernel-doc less complicated.Cc: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Jonathan Corbet
29 Oct, 2016
1 commit
-
Without this patch we get warnings for named variable arguments.
warning: No description found for parameter '...'
warning: Excess function parameter 'args' description in 'alloc_ordered_workqueue'Signed-off-by: Silvio Fricke
Reviewed-by: Jani Nikula
06 Sep, 2016
2 commits
-
Add yet another regex to kernel-doc to trap @param() references separately
and not produce corrupt RST markup.Signed-off-by: Jonathan Corbet
-
As far as I can tell, the handling of "..." arguments has never worked
right, so any documentation provided was ignored in favor of "variable
arguments." This makes kernel-doc handle "@...:" as documented. It does
*not* fix spots in kerneldoc comments that don't follow that convention,
but they are no more broken than before.Signed-off-by: Jonathan Corbet
01 Sep, 2016
2 commits
-
When using a typedef function like this one:
typedef bool v4l2_check_dv_timings_fnc (const struct v4l2_dv_timings * t, void * handle);The Sphinx C domain expects it to create a c:type: reference,
as that's the way it creates the type references when parsing
a c:function:: declaration.So, a declaration like:
.. c:function:: bool v4l2_valid_dv_timings (const struct v4l2_dv_timings * t, const struct v4l2_dv_timings_cap * cap, v4l2_check_dv_timings_fnc fnc, void * fnc_handle)
Will create a cross reference for :c:type:`v4l2_check_dv_timings_fnc`.
So, when outputting such typedefs in RST format, we need to handle
this special case, as otherwise it will produce those warnings:./include/media/v4l2-dv-timings.h:43: WARNING: c:type reference target not found: v4l2_check_dv_timings_fnc
./include/media/v4l2-dv-timings.h:60: WARNING: c:type reference target not found: v4l2_check_dv_timings_fnc
./include/media/v4l2-dv-timings.h:81: WARNING: c:type reference target not found: v4l2_check_dv_timings_fncSo, change the kernel-doc script to produce a RST output for the
above typedef as:
.. c:type:: v4l2_check_dv_timings_fnc**Typedef**: timings check callback
**Syntax**
``bool v4l2_check_dv_timings_fnc (const struct v4l2_dv_timings * t, void * handle);``
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jonathan Corbet -
Improve the parser to handle typedefs like:
typedef bool v4l2_check_dv_timings_fnc(const struct v4l2_dv_timings *t, void *handle);
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jonathan Corbet
25 Aug, 2016
1 commit
-
Right now, for a struct, kernel-doc produces the following output:
.. c:type:: struct v4l2_prio_state
stores the priority states
**Definition**
::
struct v4l2_prio_state {
atomic_t prios[4];
};**Members**
``atomic_t prios[4]``
array with elements to store the array prioritiesPutting a member name in verbatim and adding a continuation line
causes the LaTeX output to generate something like:
item[atomic_t prios\[4\]] array with elements to store the array prioritiesEverything inside "item" is non-breakable, with may produce
lines bigger than the column width.Also, for function members, like:
int (* rx_read) (struct v4l2_subdev *sd, u8 *buf, size_t count,ssize_t *num);
It puts the name of the member at the end, like:
int (*) (struct v4l2_subdev *sd, u8 *buf, size_t count,ssize_t *num) read
With is very confusing.
The best is to highlight what really matters: the member name.
is a secondary information.So, change kernel-doc, for it to produce the output on a different way:
**Members**
``prios[4]``
array with elements to store the array priorities
Also, as the type is not part of LaTeX "item[]", LaTeX will split it into
multiple lines, if needed.So, both LaTeX/PDF and HTML outputs will look good.
It should be noticed, however, that the way Sphinx LaTeX output handles
things like:Foo
baris different than the HTML output. On HTML, it will produce something
like:**Foo**
barWhile, on LaTeX, it puts both foo and bar at the same line, like:
**Foo** bar
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jonathan Corbet
23 Aug, 2016
1 commit
-
This reverts commit a88b1672d4ddf9895eb53e6980926d5e960dea8e.
From the origin comit log::
The RST cpp:function handler is very pedantic: it doesn't allow any
macros like __user on itSince the kernel-doc parser does NOT make use of the cpp:domain, there
is no need to change the kernel-doc parser eleminating the address_space
tags.Signed-off-by: Markus Heiser
Signed-off-by: Jonathan Corbet
23 Jul, 2016
1 commit
-
The RST cpp:function handler is very pedantic: it doesn't allow any
macros like __user on it:Documentation/media/kapi/dtv-core.rst:28: WARNING: Error when parsing function declaration.
If the function has no return type:
Error in declarator or parameters and qualifiers
Invalid definition: Expecting "(" in parameters_and_qualifiers. [error at 8]
ssize_t dvb_ringbuffer_pkt_read_user (struct dvb_ringbuffer * rbuf, size_t idx, int offset, u8 __user * buf, size_t len)
--------^
If the function has a return type:
Error in declarator or parameters and qualifiers
If pointer to member declarator:
Invalid definition: Expected '::' in pointer to member (function). [error at 37]
ssize_t dvb_ringbuffer_pkt_read_user (struct dvb_ringbuffer * rbuf, size_t idx, int offset, u8 __user * buf, size_t len)
-------------------------------------^
If declarator-id:
Invalid definition: Expecting "," or ")" in parameters_and_qualifiers, got "*". [error at 102]
ssize_t dvb_ringbuffer_pkt_read_user (struct dvb_ringbuffer * rbuf, size_t idx, int offset, u8 __user * buf, size_t len)
------------------------------------------------------------------------------------------------------^So, we have to remove it from the function prototype.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jonathan Corbet
18 Jul, 2016
1 commit
-
While trying to make gpu docs warning free I stumbled over one output
which wasn't following proper compiler error output standards. Fix it
up for more quickfix awesomeness.Cc: Jonathan Corbet
Cc: Jani Nikula
Cc: linux-doc@vger.kernel.org
Signed-off-by: Daniel Vetter
Signed-off-by: Jonathan Corbet
10 Jun, 2016
7 commits
-
Scan all input files for EXPORT_SYMBOLs along with the explicitly
specified export files before actually parsing anything.Signed-off-by: Jani Nikula
-
If the kernel-doc comments for functions are not in the same file as the
EXPORT_SYMBOL statements, the -export and -internal output selections do
not work as expected. This is typically the case when the kernel-doc
comments are in header files next to the function declarations and the
EXPORT_SYMBOL statements are next to the function definitions in the
source files.Let the user specify additional source files in which to look for the
EXPORT_SYMBOLs using the new -export-file FILE option, which may be
given multiple times.The pathological example for this is include/net/mac80211.h, which has
all the kernel-doc documentation for the exported functions defined in a
plethora of source files net/mac80211/*.c.Signed-off-by: Jani Nikula
-
Reduce duplication in follow-up work. No functional changes.
Signed-off-by: Jani Nikula
-
Signed-off-by: Jani Nikula
-
Since
commit 32217761ee9db0215350dfe1ca4e66f312fb8c54
Author: Jani Nikula
Date: Sun May 29 09:40:44 2016 +0300kernel-doc: concatenate contents of colliding sections
we started getting (more) errors on duplicate section names, especially
on the default section name "Description":include/net/mac80211.h:3174: warning: duplicate section name 'Description'
This is usually caused by a slightly unorthodox placement of parameter
descriptions, like in the above case, and kernel-doc resetting back to
the default section more than once within a kernel-doc comment.Ignore warnings on the duplicate section name automatically assigned by
kernel-doc, and only consider explicitly user assigned duplicate section
names an issue.Signed-off-by: Jani Nikula
-
No functional changes.
Signed-off-by: Jani Nikula
-
Lots of kerneldoc entries use "example:" or "note:" as section headers.
Until such a time as we can make them use proper markup, make them work as
intended.Signed-off-by: Jonathan Corbet
04 Jun, 2016
1 commit
-
Opt-in since this wreaks the rst output and must be removed
by consumers again. This is useful to adjust the linenumbers
for included kernel-doc snippets in shinx. With that sphinx
error message will be accurate when there's issues with the
rst-ness of the kernel-doc comments.Especially when transitioning a new docbook .tmpl to .rst this
is extremely useful, since you can just use your editors compilation
quickfix list to accurately jump from error to error.v2:
- Also make sure that we filter the LINENO for purpose/at declaration
start so it only shows for selected blocks, not all of them (Jani).
While at it make it a notch more accurate.
- Avoid undefined $lineno issues. I tried filtering these out at the
callsite, but Jani spotted more when linting the entire kernel.
Unamed unions and similar things aren't stored consistently and end
up with an undefined line number (but also no kernel-doc text, just
the parameter type). Simplify things and filter undefined line
numbers in print_lineno() to catch them all.v3: Fix LINENO 0 issue for kernel-doc comments without @param: lines
or any other special sections that directly jump to the description
after the "name - purpose" line. Only really possible for functions
without parameters. Noticed by Jani.Cc: Jani Nikula
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet
Signed-off-by: Daniel Vetter
Signed-off-by: Jani Nikula
03 Jun, 2016
2 commits
-
state3 = prototype parsing, so name them accordingly.
Cc: Jani Nikula
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet
Signed-off-by: Daniel Vetter
Signed-off-by: Jani Nikula -
Further up in the state machinery we switch from STATE_NAME to
STATE_DOCBLOCK when we match /$doc_block/. Which means this block of
code here is entirely unreachable, unless there are multiple DOC:
sections within a single kernel-doc comment.Getting a list of all the files with more than one DOC: section using
$ git grep -c " * DOC:" | grep -v ":1$"
and then doing a full audit of them reveals there are no such comment
blocks in the kernel.Supporting multiple DOC: sections in a single kernel-doc comment does
not seem like a recommended way of doing things anyway, so nuke the code
for simplicity.Cc: Jani Nikula
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet
Signed-off-by: Daniel Vetter
[Jani: amended the commit message]
Signed-off-by: Jani Nikula
30 May, 2016
5 commits
-
If the documentation comment does not have params or sections, the
section heading may leak from the previous documentation comment.Signed-off-by: Jani Nikula
-
If there are multiple sections with the same section name, the current
implementation results in several sections by the same heading, with the
content duplicated from the last section to all. Even if there's the
error message, a more graceful approach is to combine all the
identically named sections into one, with concatenated contents.With the supported sections already limited to select few, there are
massively fewer collisions than there used to be, but this is still
useful for e.g. when function parameters are documented in the middle of
a documentation comment, with description spread out above and
below. (This is not a recommended documentation style, but used in the
kernel nonetheless.)We can now also demote the error to a warning.
Signed-off-by: Jani Nikula
-
kernel-doc currently identifies anything matching "section header:"
(specifically a string of word characters and spaces followed by a
colon) as a new section in the documentation comment, and renders the
section header accordingly.Unfortunately, this turns all uses of colon into sections, mostly
unintentionally. Considering the output, erroneously creating sections
when not intended is always worse than erroneously not creating sections
when intended. For example, a line with "http://example.com" turns into
a "http" heading followed by "//example.com" in normal text style, which
is quite ugly. OTOH, "WARNING: Beware of the Leopard" is just fine even
if "WARNING" does not turn into a heading.It is virtually impossible to change all the kernel-doc comments, either
way. The compromise is to pick the most commonly used and depended on
section headers (with variants) and accept them as section headers.The accepted section headers are, case insensitive:
* description:
* context:
* return:
* returns:Additionally, case sensitive:
* @return:
All of the above are commonly used in the kernel-doc comments, and will
result in worse output if not identified as section headers. Also,
kernel-doc already has some special handling for all of them, so there's
nothing particularly controversial in adding more special treatment for
them.While at it, improve the whitespace handling surrounding section
names. Do not consider the whitespace as part of the name.Signed-off-by: Jani Nikula
-
Yes, for our purposes the type should contain typedef.
Signed-off-by: Jani Nikula
-
The latter isn't special to rst.
Signed-off-by: Jani Nikula