docs: kernel-doc: Get rid of xml_escape() and friends

XML escaping is a worry that came with DocBook, which we no longer have any
dealings with. So get rid of the useless xml_escape()/xml_unescape(

docs: kernel-doc: Get rid of xml_escape() and friends

XML escaping is a worry that came with DocBook, which we no longer have any
dealings with. So get rid of the useless xml_escape()/xml_unescape()
functions. No change to the generated output.

Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel_doc: better handle show warnings logic

The logic with inhibits warnings for definitions that is not
output is incomplete: it doesn't cover the cases where
OUTPUT_INTERNAL and OUTPUT_

scripts: kernel_doc: better handle show warnings logic

The logic with inhibits warnings for definitions that is not
output is incomplete: it doesn't cover the cases where
OUTPUT_INTERNAL and OUTPUT_EXPORTED are used.

As the most common case is OUTPUT_ALL, place it first,
in order to optimize a litte bit the check logic.

Fixes: 2defb2729217 ("scripts: kernel-doc: apply filtering rules to warnings")
Reported-by: Randy Dunlap <[email protected]>
Acked-and-Tested-by: Randy Dunlap <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel-doc: apply filtering rules to warnings

When kernel-doc is called with output selection filters,
it will be called lots of time for a single file. If
there is a warning present there,

scripts: kernel-doc: apply filtering rules to warnings

When kernel-doc is called with output selection filters,
it will be called lots of time for a single file. If
there is a warning present there, it means that it may
print hundreds of identical warnings.

Worse than that, the -function NAME actually filters only
functions. So, it makes no sense at all to print warnings
for structs or enums.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel-doc: improve nested logic to handle multiple identifiers

It is possible to use nested structs like:

struct {
struct {
void *arg1;
} st1, st2, *st3, st4;
};

Handling it requires

scripts: kernel-doc: improve nested logic to handle multiple identifiers

It is possible to use nested structs like:

struct {
struct {
void *arg1;
} st1, st2, *st3, st4;
};

Handling it requires to split each parameter. Change the logic
to allow such definitions.

In order to test the new nested logic, the following file
was used to test

<code>
struct foo { int a; }; /* Just to avoid errors if compiled */

/**
* struct my_struct - a struct with nested unions and structs
* @arg1: first argument of anonymous union/anonymous struct
* @arg2: second argument of anonymous union/anonymous struct
* @arg1b: first argument of anonymous union/anonymous struct
* @arg2b: second argument of anonymous union/anonymous struct
* @arg3: third argument of anonymous union/anonymous struct
* @arg4: fourth argument of anonymous union/anonymous struct
* @bar.st1.arg1: first argument of struct st1 on union bar
* @bar.st1.arg2: second argument of struct st1 on union bar
* @bar.st1.bar1: bar1 at st1
* @bar.st1.bar2: bar2 at st1
* @bar.st2.arg1: first argument of struct st2 on union bar
* @bar.st2.arg2: second argument of struct st2 on union bar
* @bar.st3.arg2: second argument of struct st3 on union bar
* @f1: nested function on anonimous union/struct
* @bar.st2.f2: nested function on named union/struct
*/
struct my_struct {
/* Anonymous union/struct*/
union {
struct {
char arg1 : 1;
char arg2 : 3;
};
struct {
int arg1b;
int arg2b;
};
struct {
void *arg3;
int arg4;
int (*f1)(char foo, int bar);
};
};
union {
struct {
int arg1;
int arg2;
struct foo bar1, *bar2;
} st1; /* bar.st1 is undocumented, cause a warning */
struct {
void *arg1; /* bar.st3.arg1 is undocumented, cause a warning */
int arg2;
int (*f2)(char foo, int bar); /* bar.st3.fn2 is undocumented, cause a warning */
} st2, st3, *st4;
int (*f3)(char foo, int bar); /* f3 is undocumented, cause a warning */
} bar; /* bar is undocumented, cause a warning */

/* private: */
int undoc_privat; /* is undocumented but private, no warning */

/* public: */
int undoc_public; /* is undocumented, cause a warning */
};
</code>

It produces the following warnings, as expected:

test2.h:57: warning: Function parameter or member 'bar' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'bar.st1' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'bar.st2' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'bar.st3' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'bar.st3.arg1' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'bar.st3.f2' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'bar.st4' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'bar.st4.arg1' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'bar.st4.arg2' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'bar.st4.f2' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'bar.f3' not described in 'my_struct'
test2.h:57: warning: Function parameter or member 'undoc_public' not described in 'my_struct'

Suggested-by: Markus Heiser <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel-doc: handle nested struct function arguments

Function arguments are different than usual ones. So, an
special logic is needed in order to handle such arguments
on nested structs.

Si

scripts: kernel-doc: handle nested struct function arguments

Function arguments are different than usual ones. So, an
special logic is needed in order to handle such arguments
on nested structs.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel-doc: print the declaration name on warnings

The logic at create_parameterlist()'s ancillary push_parameter()
function has already a way to output the declaration name, with
would hel

scripts: kernel-doc: print the declaration name on warnings

The logic at create_parameterlist()'s ancillary push_parameter()
function has already a way to output the declaration name, with
would help to discover what declaration is missing.

However, currently, the logic is utterly broken, as it uses
the var $type with a wrong meaning. With the current code,
it will never print anything. I suspect that originally
it was using the second argument of output_declaration().

I opted to not rely on a globally defined $declaration_name,
but, instead, to pass it explicitly as a parameter.

While here, I removed a unaligned check for !$anon_struct_union.
This is not needed, as, if $anon_struct_union is not zero,
$parameterdescs{$param} will be defined.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel-doc: get rid of $nested parameter

The check_sections() function has a $nested parameter, meant
to identify when a nested struct is present. As we now have
a logic that handles it, ge

scripts: kernel-doc: get rid of $nested parameter

The check_sections() function has a $nested parameter, meant
to identify when a nested struct is present. As we now have
a logic that handles it, get rid of such parameter.

Suggested-by: Markus Heiser <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel-doc: parse next structs/unions

There are several places within the Kernel tree with nested
structs/unions, like this one:

struct ingenic_cgu_clk_info {
const char *name;
e

scripts: kernel-doc: parse next structs/unions

There are several places within the Kernel tree with nested
structs/unions, like this one:

struct ingenic_cgu_clk_info {
const char *name;
enum {
CGU_CLK_NONE = 0,
CGU_CLK_EXT = BIT(0),
CGU_CLK_PLL = BIT(1),
CGU_CLK_GATE = BIT(2),
CGU_CLK_MUX = BIT(3),
CGU_CLK_MUX_GLITCHFREE = BIT(4),
CGU_CLK_DIV = BIT(5),
CGU_CLK_FIXDIV = BIT(6),
CGU_CLK_CUSTOM = BIT(7),
} type;
int parents[4];
union {
struct ingenic_cgu_pll_info pll;
struct {
struct ingenic_cgu_gate_info gate;
struct ingenic_cgu_mux_info mux;
struct ingenic_cgu_div_info div;
struct ingenic_cgu_fixdiv_info fixdiv;
};
struct ingenic_cgu_custom_info custom;
};
};

Currently, such struct is documented as:

**Definition**

::
struct ingenic_cgu_clk_info {
const char * name;
};

**Members**

``name``
name of the clock

With is obvioulsy wrong. It also generates an error:
drivers/clk/ingenic/cgu.h:169: warning: No description found for parameter 'enum'

However, there's nothing wrong with this kernel-doc markup: everything
is documented there.

It makes sense to document all fields there. So, add a
way for the core to parse those structs.

With this patch, all documented fields will properly generate
documentation.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel-doc: replace tabs by spaces

Sphinx has a hard time dealing with tabs, causing it to
misinterpret paragraph continuation.

As we're now mainly focused on supporting ReST output,
repla

scripts: kernel-doc: replace tabs by spaces

Sphinx has a hard time dealing with tabs, causing it to
misinterpret paragraph continuation.

As we're now mainly focused on supporting ReST output,
replace tabs by spaces, in order to avoid troubles when
the output is parsed by Sphinx.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel-doc: change default to ReST format

Right now, if kernel-doc is called without arguments, it
defaults to man pages. IMO, it makes more sense to
default to ReST, as this is the output

scripts: kernel-doc: change default to ReST format

Right now, if kernel-doc is called without arguments, it
defaults to man pages. IMO, it makes more sense to
default to ReST, as this is the output that it is most
used nowadays, and it easier to check if everything got
parsed fine on an enriched text mode format.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel-doc: improve argument handling

Right now, if one uses "--rst" instead of "-rst", it just
ignore the argument and produces a man page. Change the
logic to accept both "-cmd" and "--cm

scripts: kernel-doc: improve argument handling

Right now, if one uses "--rst" instead of "-rst", it just
ignore the argument and produces a man page. Change the
logic to accept both "-cmd" and "--cmd". Also, if
"cmd" doesn't exist, print the usage information and exit.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: kernel-doc: get rid of unused output formats

Since there isn't any docbook code anymore upstream,
we can get rid of several output formats:

- docbook/xml, html, html5 and list formats were

scripts: kernel-doc: get rid of unused output formats

Since there isn't any docbook code anymore upstream,
we can get rid of several output formats:

- docbook/xml, html, html5 and list formats were used by
the old build system;
- As ReST is text, there's not much sense on outputting
on a different text format.

After this patch, only man and rst output formats are
supported.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

docs: get rid of kernel-doc-nano-HOWTO.txt

Everything there is already described at
Documentation/doc-guide/kernel-doc.rst. So, there's no reason why
to keep it anymore.

Signed-off-by: Mauro Carval

docs: get rid of kernel-doc-nano-HOWTO.txt

Everything there is already described at
Documentation/doc-guide/kernel-doc.rst. So, there's no reason why
to keep it anymore.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

kernel-doc: parse DECLARE_KFIFO and DECLARE_KFIFO_PTR()

On media, we now have an struct declared with:

struct lirc_fh {
struct list_head list;
struct rc_dev *rc;
int

kernel-doc: parse DECLARE_KFIFO and DECLARE_KFIFO_PTR()

On media, we now have an struct declared with:

struct lirc_fh {
struct list_head list;
struct rc_dev *rc;
int carrier_low;
bool send_timeout_reports;
DECLARE_KFIFO_PTR(rawir, unsigned int);
DECLARE_KFIFO_PTR(scancodes, struct lirc_scancode);
wait_queue_head_t wait_poll;
u8 send_mode;
u8 rec_mode;
};

gpiolib.c has a similar declaration with DECLARE_KFIFO().

Currently, those produce the following error:

./include/media/rc-core.h:96: warning: No description found for parameter 'int'
./include/media/rc-core.h:96: warning: No description found for parameter 'lirc_scancode'
./include/media/rc-core.h:96: warning: Excess struct member 'rawir' description in 'lirc_fh'
./include/media/rc-core.h:96: warning: Excess struct member 'scancodes' description in 'lirc_fh'
../drivers/gpio/gpiolib.c:601: warning: No description found for parameter '16'
../drivers/gpio/gpiolib.c:601: warning: Excess struct member 'events' description in 'lineevent_state'

So, teach kernel-doc how to parse DECLARE_KFIFO() and DECLARE_KFIFO_PTR().

While here, relax at the past DECLARE_foo() macros, accepting a random
number of spaces after comma.

The addition of DECLARE_KFIFO() was
Suggested-by: Randy Dunlap <[email protected]>

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none

My bisect scripts starting running into build failures when trying to
compile 4.15-rc1 with the builds failing with th

scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none

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 <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

Add optional check for bad kernel-doc comments

Implement a '-none' output mode for kernel-doc which will only output
warning messages, and suppresses the warning message about there being
no kernel-

Add optional check for bad kernel-doc comments

Implement a '-none' output mode for kernel-doc which will only output
warning messages, and suppresses the warning message about there being
no kernel-doc in the file.

If the build has requested additional warnings, automatically check all
.c files. This patch does not check .h files. Enabling the warning
by default would add about 1300 warnings, so it's default off for now.
People who care can use this to check they didn't break the docs and
maybe we'll get all the warnings fixed and be able to enable this check
by default in the future.

Signed-off-by: Matthew Wilcox <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

kmemcheck: rip it out

Fix up makefiles, remove references, and git rm kmemcheck.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <alexan

kmemcheck: rip it out

Fix up makefiles, remove references, and git rm kmemcheck.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Vegard Nossum <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: Tim Hansen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/kernel-doc: warn on excess enum value descriptions

The existing message
"Excess struct/union/enum/typedef member [...]"
made it sound like this would already be done, but the
code is never

scripts/kernel-doc: warn on excess enum value descriptions

The existing message
"Excess struct/union/enum/typedef member [...]"
made it sound like this would already be done, but the
code is never invoked for enums or typedefs (and really
can't be).

Add some code to the enum dumper to handle this there
instead.

While at it, also make the above message more accurate
by simply dumping the type that was passed in, and pass
the struct/union differentiation in.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

kernel-doc parser mishandles declarations split into lines

Reported by Johannes Berg [1]. Problem here: function
process_proto_type() concatenates the striped lines of declaration
without any white

kernel-doc parser mishandles declarations split into lines

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/[email protected]/msg12410.html

Signed-off-by: Markus Heiser <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts/kernel-doc: handle DECLARE_HASHTABLE

DECLARE_HASHTABLE needs similar handling to DECLARE_BITMAP
because otherwise kernel-doc assumes the member name is the
second, not first macro parameter.

scripts/kernel-doc: handle DECLARE_HASHTABLE

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 <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: Switch to more portable Perl shebang

The default NetBSD package manager is pkgsrc and it installs Perl
along other third party programs under custom and configurable prefix.
The default pre

scripts: Switch to more portable Perl shebang

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 <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

scripts/kernel-doc: fix handling of parameters with parenthesis

lib/crc32c defines one parameter as:
const u32 (*tab)[256]

Better handle parenthesis, to avoid those warnings:

./lib/crc32.c:149: w

scripts/kernel-doc: fix handling of parameters with parenthesis

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 <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts/kernel-doc: fix parser for apostrophes

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

scripts/kernel-doc: fix parser for apostrophes

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 <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

kernel-doc: Handle returning pointers to pointers

Clearly nobody ever tried to build the documentation for the radix tree
before:

include/linux/radix-tree.h:400: warning: cannot understand function

kernel-doc: Handle returning pointers to pointers

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 <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

kernel-doc: properly document array arguments of function

Documentation for array parameters passed in a function, like the first
argument in the function below, weren't getting exported in the rst

kernel-doc: properly document array arguments of function

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 <[email protected]>
Fixes: c0d1b6ee780a ("kernel-doc: produce RestructuredText output")
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...