Fix false positive warning of identifiers ending in signed with an =
assignment of WARNING: Prefer 'signed int' to bare use of 'signed'.

Link: http://lkml.kernel.org/r/6a0e24c3e9102337528ecfcbbe91a0eb5b4820ed.1469529497.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Reported-by: NAlan Douglas <alanjhd@gmail.com>
Acked-by: NAndy Whitcroft <apw@canonical.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

BIT macro cannot be exported to UAPI, don't complain about it.

Link: http://lkml.kernel.org/r/1468707033-16173-1-git-send-email-tomas.winkler@intel.comSigned-off-by: NTomas Winkler <tomas.winkler@intel.com>
Acked-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Using \b isn't good enough to isolate what appears to be a commit id in
a commit message.

Make sure there is a space or a quote like character after a continuous
run of hexadecimal characters that could be a commit id.

Link: http://lkml.kernel.org/r/fdd22b47463a21c21132edbb8aa35e372950a1e6.1468869915.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Cc: "Zhuo, Qiuxu" <qiuxu.zhuo@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Sanitise the lines that contain c99 comments so that the error doesn't
get emitted.

Link: http://lkml.kernel.org/r/d4d22c34ad7bcc1bceb52f0742f76b7a6d585235.1468368420.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

These are also possible single line uses that exceed the generic maximum
line length (typically 80 columns)

Link: http://lkml.kernel.org/r/32a6a85fbd6161f1bb55ce176a464e44591afc5b.1468368420.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If a vcs is used, look to see if the vcs tracks the file specified and
so the -f option becomes optional.

Link: http://lkml.kernel.org/r/7c86a8df0d48770c45778a43b6b3e4627b2a90ee.1469746395.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Several build configurations had already disabled this warning because
it generates a lot of false positives.  But some had not, and it was
still enabled for "allmodconfig" builds, for example.

Looking at the warnings produced, every single one I looked at was a
false positive, and the warnings are frequent enough (and big enough)
that they can easily hide real problems that you don't notice in the
noise generated by -Wmaybe-uninitialized.

The warning is good in theory, but this is a classic case of a warning
that causes more problems than the warning can solve.

If gcc gets better at avoiding false positives, we may be able to
re-enable this warning.  But as is, we're better off without it, and I
want to be able to see the *real* warnings.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

 - Add a proper comment to page->_mapcount.

 - Introduce a macro for generating helper functions.

 - Place all special page->_mapcount values next to each other so that
   readers can see all possible values and so we don't get duplicates.

Link: http://lkml.kernel.org/r/502f49000e0b63e6c62e338fac6b420bf34fb526.1464079537.git.vdavydov@virtuozzo.comSigned-off-by: NVladimir Davydov <vdavydov@virtuozzo.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Python divisions are integer divisions unless at least one parameter is
a float.  The current bloat-o-meter fails to print sub-percentage
changes:

  Total: Before=10515408, After=10604060, chg 0.000000%

Force float division by using one float and pretty the print to two
significant decimals:

  Total: Before=10515408, After=10604060, chg +0.84%

Link: http://lkml.kernel.org/r/1465980311-23814-1-git-send-email-riku.voipio@linaro.orgSigned-off-by: NRiku Voipio <riku.voipio@linaro.org>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

changeset b7e67f6c ("doc-rst: linux_tv: supress lots of warnings")
were meant to touch only on media files, but it also touched
at this script by mistake. Revert such change.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

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: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Determining which kernel config options need to be enabled for a
given devicetree can be a painful process.  Create a new tool to
find the drivers that may match a devicetree node compatible,
find the kernel config options that enable the driver, and
optionally report whether the kernel config option is enabled.
Signed-off-by: NGaurav Minocha <gaurav.minocha.os@gmail.com>
Signed-off-by: NFrank Rowand <frank.rowand@am.sony.com>
Signed-off-by: NRob Herring <robh@kernel.org>

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 <corbet@lwn.net>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: linux-doc@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This doesn't belong at documentation. Move it to scripts.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

There are several documentation stuff under Documentation/dvb.

Move them to Documentation/media/dvb-drivers and rename them to
rst, as they'll soon be converted to rst files.

No changes at the documentation.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Update AnalyzeSuspend to v4.2:

 - kprobe support for function tracing
 - config file support in lieu of command line options
 - advanced callgraph support for function debug
 - dev mode for monitoring common sources of delay, e.g. msleep, udelay
 - many bug fixes and formatting upgrades
Signed-off-by: NTodd Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This reverts commit e127a73d ("scripts/gdb: add a Radix Tree
Parser")

The python implementation of radix-tree was merged at the same time as
the radix-tree system was heavily reworked from commit e9256efc
("radix-tree: introduce radix_tree_empty") to 3bcadd6f ("radix-tree:
free up the bottom bit of exceptional entries for reuse") and no longer
functions, but also prevents other gdb scripts from loading.

This functionality has not yet hit a release, so simply remove it for
now

Link: http://lkml.kernel.org/r/1467127337-11135-6-git-send-email-kieran@bingham.xyzSigned-off-by: NKieran Bingham <kieran@bingham.xyz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Python doesn't do automatic expansion of paths.  In case one passes path
of the from ~/foo/bar the gdb scripts won't automatically expand that
and as a result the symbols files won't be loaded.

Fix this by explicitly expanding all paths which begin with "~"

Link: http://lkml.kernel.org/r/1467127337-11135-5-git-send-email-kieran@bingham.xyzSigned-off-by: NNikolay Borisov <n.borisov.lkml@gmail.com>
Signed-off-by: NKieran Bingham <kieran@bingham.xyz>
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since scripts/gdb/linux/constants.py is autogenerated, this should have
been added to .gitignore when it was introduced.

Fixes: f197d75f ("scripts/gdb: provide linux constants")
Link: http://lkml.kernel.org/r/1467127337-11135-4-git-send-email-kieran@bingham.xyzSigned-off-by: NOmar Sandoval <osandov@fb.com>
Signed-off-by: NKieran Bingham <kieran@bingham.xyz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The autogenerated constants.py file was only being built on the initial
call, and if the constants.py.in file changed.  As we are utilising the
CPP hooks, we can successfully use the call if_changed_dep rules to
determine when to rebuild the file based on it's inclusions.

Link: http://lkml.kernel.org/r/1467127337-11135-3-git-send-email-kieran@bingham.xyzSigned-off-by: NKieran Bingham <kieran@bingham.xyz>
Reported-by: NJan Kiszka <jan.kiszka@web.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The constants.py generation, involves a rule to link into the main
makefile.  This rule has no command and generates a spurious warning
message in the build logs when CONFIG_SCRIPTS_GDB is enabled.

Fix simply by giving a no-op action

Link: http://lkml.kernel.org/r/1467127337-11135-2-git-send-email-kieran@bingham.xyzSigned-off-by: NKieran Bingham <kieran@bingham.xyz>
Reported-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The __pmem address space was meant to annotate codepaths that touch
persistent memory and need to coordinate a call to wmb_pmem().  Now that
wmb_pmem() is gone, there is little need to keep this annotation.

Cc: Christoph Hellwig <hch@lst.de>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

When a header file is removed from generic-y (often accompanied by the
addition of an arch specific header), the generated wrapper file will
persist, and in some cases may still take precedence over the new arch
header.

For example commit f1fe2d21 ("MIPS: Add definitions for extended
context") removed ucontext.h from generic-y in arch/mips/include/asm/,
and added an arch/mips/include/uapi/asm/ucontext.h. The continued use of
the wrapper when reusing a dirty build tree resulted in build failures
in arch/mips/kernel/signal.c:

arch/mips/kernel/signal.c: In function ‘sc_to_extcontext’:
arch/mips/kernel/signal.c:142:12: error: ‘struct ucontext’ has no member named ‘uc_extcontext’
  return &uc->uc_extcontext;
            ^
Fix by detecting and removing wrapper headers in generated header
directories that do not correspond to a filename in generic-y, genhdr-y,
or the newly introduced generated-y.
Reported-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Reported-by: NHauke Mehrtens <hauke@hauke-m.de>
Reported-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Cc: linux-arch@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-kbuild@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Michal Marek <mmarek@suse.com>
Link: http://lkml.kernel.org/r/1466808144-23209-3-git-send-email-james.hogan@imgtec.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The conversion script added some comments at the end.
They point to the original DocBook files, with will be
removed after the manual fixes. So, they'll be pointing
to nowere. So, remove those comments.

They'll be forever stored at the Kernel tree. So, if
someone wants the references, it is just a matter of
looking at the backlog.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The c language parser checks if there are duplicated object
definitions. That causes lots of warnings like:
	WARNING: duplicate C object description of ioctl

Let's remove those by telling Sphinx that the language for
those objects are c++. The look of the descriptions will
be close, and the warnings will be gone.

Please notice that we had to keep a few of them as C, as
the c++ parser seems to be broken when it finds an enum.

Yet, this reduced from 219 warnings to 143, with is
a good thing.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Move the definition of fsl_mc_device_id to its proper location in
mod_devicetable.h, and add fsl-mc bus support to devicetable-offsets.c
and file2alias.c to enable device table matching.  With this patch udev
based module loading of fsl-mc drivers is supported.
Signed-off-by: NStuart Yoder <stuart.yoder@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sign-file determine the format of the X.509 certificate by reading the
first two bytes and seeing if the first byte is 0x30 and the second
0x81-0x84.  If this is the case, assume it's DER encoded, otherwise assume
it to be PEM encoded.

Without this, it gets awkward to deal with the error messages from
d2i_X509_bio() when we want to call BIO_reset() and then PEM_read_bio() in
case the certificate was PEM encoded rather than X.509 encoded.
Reported-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Tested-by: NBen Hutchings <ben@decadent.org.uk>
cc: David Woodhouse <dwmw2@infradead.org>
cc: Juerg Haefliger <juerg.haefliger@hpe.com>
cc: Ben Hutchings <ben@decadent.org.uk>

Scan all input files for EXPORT_SYMBOLs along with the explicitly
specified export files before actually parsing anything.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

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: NJani Nikula <jani.nikula@intel.com>

Reduce duplication in follow-up work. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Since

commit 32217761
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Sun May 29 09:40:44 2016 +0300

    kernel-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: NJani Nikula <jani.nikula@intel.com>

No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

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: NJonathan Corbet <corbet@lwn.net>

Because of an improper dereference, a stray 'C' character was output to
the modalias when no 'compatible' was specified. This is the case for
some old PowerMac drivers which only set the 'name' property. Fix it to
let them match again.
Reported-by: NMathieu Malaterre <malat@debian.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Tested-by: NMathieu Malaterre <malat@debian.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Fixes: 6543becf ("mod/file2alias: make modalias generation safe for cross compiling")
Cc: stable@vger.kernel.org # v3.9+
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

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 <jani.nikula@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Some lines in a commit log appear to be commit SHA1 ids like:

  ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
  Link: http://lkml.kernel.org/r/40e03fd7aaf1f55c75d787128d6d17c5a71226c2.1464358556.git.vdavydov@virtuozzo.com

Reduce the false positives.

Link: http://lkml.kernel.org/r/eda977eaa8328fef42bb3c87935d97e10ea8ff67.1464384023.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Reported-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

state3 = prototype parsing, so name them accordingly.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

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 <jani.nikula@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[Jani: amended the commit message]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If the documentation comment does not have params or sections, the
section heading may leak from the previous documentation comment.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>