| Age | Commit message (Collapse) | Author |
|---|
|
There are a couple of problems with the decodecode script and arm64:
1. AArch64 objdump refuses to disassemble .4byte directives as instructions,
insisting that they are data values and displaying them as:
a94153f3 .word 0xa94153f3 <-- trapping instruction
This is resolved by using the .inst directive instead.
2. Disassembly of branch instructions attempts to provide the target as
an offset from a symbol, e.g.:
0: 34000082 cbz w2, 10 <.text+0x10>
however this falls foul of the grep -v, which matches lines containing
".text" and ends up removing all branch instructions from the dump.
This patch resolves both issues by using the .inst directive for 4-byte
quantities on arm64 and stripping the resulting binaries (as is done on
arm already) to remove the mapping symbols.
Link: http://lkml.kernel.org/r/1506596147-23630-1-git-send-email-will.deacon@arm.com
Signed-off-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
gcc-8 reports many -Wpacked-not-aligned warnings. The below are some
examples.
./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
} __attribute__ ((packed));
./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
} __attribute__ ((packed));
./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
} __attribute__ ((packed));
This patch suppresses this kind of warnings for default setting.
Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
str_ends_with() tests if the given token ends with a particular string.
Currently, it is used to check file paths without $(srctree).
Actually, we have one more place where this helper is useful. Use it
to check if CONFIG option ends with _MODULE.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
parse_dep_file() has too much indentation, and puts the code far to
the right. This commit refactors the code and reduces the one level
of indentation.
strrcmp() computes 'slen' by itself, but the caller already knows the
length of the token, so 'slen' can be passed via function argument.
With this, we can swap the order of strrcmp() and "*p = \0;"
Also, strrcmp() is an ambiguous function name. Flip the logic and
rename it to str_ends_with().
I added a new helper is_ignored_file() - this returns 1 if the token
represents a file that should be ignored.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
I do not mind global variables where they are useful enough. In this
case, I do not see a good reason to use global variables since they
are just referenced in shallow places. It is easy to pass them via
function arguments.
I squashed print_cmdline() into main() since it is just one line code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Each token in the depfile is copied to the temporary buffer 's' to
terminate the token with zero. We do not need to do this any more
because the parsed buffer is now writable. Insert '\0' directly in
the buffer without calling memcpy().
<limits.h> is no longer necessary. (It was needed for PATH_MAX).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Now, do_config_files() and print_deps() are almost the same. Only
the difference is the parser function called (parse_config_file vs
parse_dep_file).
We can reduce the code duplication by factoring out the common code
into read_file() - this function allocates a buffer and loads a file
to it. It returns the pointer to the allocated buffer. (As before,
it bails out by exit(2) for any error.) The caller must free the
buffer when done.
Having empty source files is possible; fixdep should simply skip them.
I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte
buffer for an empty file. strstr() will immediately return NULL, and
this is what we expect.
On the other hand, an empty dep_file should be treated as an error.
In this case, parse_dep_file() will error out with "no targets found"
and it is a correct error message.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Commit dee81e988674 ("fixdep: faster CONFIG_ search") changed how to
read files in which CONFIG options are searched. It used malloc()
and read() instead of mmap() because it needed to zero-terminate the
buffer in order to use strstr(). print_deps() was left untouched
since there was no reason to change it.
Now, I have two motivations to change it in the same way.
- do_config_file() and print_deps() do quite similar things; they
open a file, load it onto memory, and pass it to a parser function.
If we use malloc() and read() for print_deps() too, we can factor
out the common code. (I will do this in the next commit.)
- parse_dep_file() copies each token to a temporary buffer because
it needs to zero-terminate it to be passed to printf(). It is not
possible to modify the buffer directly because it is mmap'ed with
O_RDONLY. If we load the file content into a malloc'ed buffer, we
can insert '\0' after each token, and save memcpy(). (I will do
this in the commit after next.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
<arpa/inet.h> was included for ntohl(), but it was removed by
commit dee81e988674 ("fixdep: faster CONFIG_ search").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 pti bits and fixes from Thomas Gleixner:
"This last update contains:
- An objtool fix to prevent a segfault with the gold linker by
changing the invocation order. That's not just for gold, it's a
general robustness improvement.
- An improved error message for objtool which spares tearing hairs.
- Make KASAN fail loudly if there is not enough memory instead of
oopsing at some random place later
- RSB fill on context switch to prevent RSB underflow and speculation
through other units.
- Make the retpoline/RSB functionality work reliably for both Intel
and AMD
- Add retpoline to the module version magic so mismatch can be
detected
- A small (non-fix) update for cpufeatures which prevents cpu feature
clashing for the upcoming extra mitigation bits to ease
backporting"
* 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
module: Add retpoline tag to VERMAGIC
x86/cpufeature: Move processor tracing out of scattered features
objtool: Improve error message for bad file argument
objtool: Fix seg fault with gold linker
x86/retpoline: Add LFENCE to the retpoline/RSB filling RSB macros
x86/retpoline: Fill RSB on context switch for affected CPUs
x86/kasan: Panic if there is not enough memory to boot
|
|
Rename kzalloc-simple to zalloc-simple since now the rule is not
specific to kzalloc function only, but also to many other zero memory
allocating functions specified in the rule.
Suggested-by: SF Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Remove the unncessary part of the warning reported, in the report
mode, so that a single warning produced does not exceed more than line
and hence improve readability of the warnings produced in the subsequent
reports to a file.
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Add more memory allocating functions that are frequently used in the
kernel code to the existing list and remove the useless casts where
it is unnecessary.
But preserve those casts having __attribute__ such as __force, __iomem,
etc. which are used by Sparse in the static analysis of the code.
Also remove two blank lines at EOF.
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Rule r does not depend on rule i (which is the include of
linux/kernel.h) so the output should not depend on i in
org and report mode.
Signed-off-by: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
There are many instances where memory is allocated using regular
allocator functions immediately followed by setting the allocated
memory to 0 value using memset.
We already have zero memory allocator functions to set the memory to
0 value instead of manually setting it using memset.
Therefore, use zero memory allocating functions instead of regular
memory allocators followed by memset 0 to remove redundant memset and
make the code more cleaner and also reduce the code size.
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Objtool segfaults when the gold linker is used with
CONFIG_MODVERSIONS=y and CONFIG_UNWINDER_ORC=y.
With CONFIG_MODVERSIONS=y, the .o file gets passed to the linker before
being passed to objtool. The gold linker seems to strip unused ELF
symbols by default, which confuses objtool and causes the seg fault when
it's trying to generate ORC metadata.
Objtool should really be running immediately after GCC anyway, without a
linker call in between. Change the makefile ordering so that objtool is
called before the linker.
Reported-and-tested-by: Markus <M4rkusXXL@web.de>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: ee9f8fce9964 ("x86/unwind: Add the ORC unwinder")
Link: http://lkml.kernel.org/r/355f04da33581f4a3bf82e5b512973624a1e23a2.1516025651.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- fix cross-compilation for architectures that setup CROSS_COMPILE in
their arch Makefile
- fix Kconfig rational operators for bool / tristate
- drop a gperf-generated file from .gitignore
* tag 'kbuild-fixes-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
genksyms: drop *.hash.c from .gitignore
kconfig: fix relational operators for bool and tristate symbols
kbuild: move cc-option and cc-disable-warning after incl. arch Makefile
|
|
This is a left-over of commit bb3290d91695 ("Remove gperf usage from
toolchain").
We do not generate a hash function any more.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
The following strings would leak before this change:
- option env="LEAKED"
- option defconfig_list="LEAKED"
These come in the form of T_WORD tokens and are always allocated on the
heap in zconf.l. Free them.
Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
LEAK SUMMARY:
definitely lost: 344,616 bytes in 14,355 blocks
...
Summary after the fix:
LEAK SUMMARY:
definitely lost: 344,568 bytes in 14,352 blocks
...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
The 'source_stmt' nonterminal takes a 'prompt', which consists of either
a T_WORD or a T_WORD_QUOTE, both of which are always allocated on the
heap in zconf.l and need to have their associated strings freed. Free
them.
The existing code already makes sure to always copy the string, but add
a warning to sym_expand_string_value() to make it clear that the string
must be copied, just in case.
Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
LEAK SUMMARY:
definitely lost: 387,504 bytes in 15,545 blocks
...
Summary after the fix:
LEAK SUMMARY:
definitely lost: 344,616 bytes in 14,355 blocks
...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Prior to this fix, zconf.y did not free symbol names from zconf.l in
these contexts:
- After T_CONFIG ('config LEAKED')
- After T_MENUCONFIG ('menuconfig LEAKED')
- After T_SELECT ('select LEAKED')
- After T_IMPLY ('imply LEAKED')
- After T_DEFAULT in a choice ('default LEAKED')
All of these come in the form of T_WORD tokens, which always have their
associated string allocated on the heap in zconf.l and need to be freed.
Fix by introducing a new nonterminal 'nonconst_symbol' which takes a
T_WORD, fetches the symbol, and then frees the T_WORD string. The
already existing 'symbol' nonterminal works the same way but also
accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE
should not be accepted in any of the contexts above, so the 'symbol'
nonterminal can't be reused here.
Fetching the symbol in 'nonconst_symbol' also removes a bunch of
sym_lookup() calls from actions.
Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
LEAK SUMMARY:
definitely lost: 711,571 bytes in 37,756 blocks
...
Summary after the fix:
LEAK SUMMARY:
definitely lost: 387,504 bytes in 15,545 blocks
...
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart
enough to handle function pointer dereference on platforms where such
dereference is required.
Link: http://lkml.kernel.org/r/20171109234830.5067-7-sergey.senozhatsky@gmail.com
To: Tony Luck <tony.luck@intel.com>
To: Fenghua Yu <fenghua.yu@intel.com>
To: Helge Deller <deller@gmx.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Paul Mackerras <paulus@samba.org>
To: Michael Ellerman <mpe@ellerman.id.au>
To: James Bottomley <jejb@parisc-linux.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jessica Yu <jeyu@kernel.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-ia64@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
|
|
do_config_file() should exit with an error code on internal run-time
errors, and not return if it fails as then the error in do_config_file()
would go unnoticed in the current code and allow the build to continue.
The exit with error code will make the build fail in those very
exceptional cases. If this occurs, this actually indicates a deeper
problem in the execution of the kernel build process.
Now, in these error cases, we do not explicitly free memory and close
the file handlers in do_config_file(), as this is covered by exit().
This issue in the fixdep script was introduced with its initial
implementation back in 2002 by the original author Kai Germaschewski with
this commit 04bd72170653 ("kbuild: Make dependencies at compile time")
in the linux history git tree, i.e.,
git://git.kernel.org/pub/scm/linux/kernel/git/history/history.git.
This issue was identified during the review of a previous patch that
intended to address a memory leak detected by a static analysis tool.
Link: https://lkml.org/lkml/2017/12/14/736
Suggested-by: Nicholas Mc Guire <der.herr@hofr.at>
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Since commit 31847b67bec0 ("kconfig: allow use of relations other than
(in)equality") it is possible to use relational operators in Kconfig
statements. However, those operators give unexpected results when
applied to bool/tristate values:
(n < y) = y (correct)
(m < y) = y (correct)
(n < m) = n (wrong)
This happens because relational operators process bool and tristate
symbols as strings and m sorts before n. It makes little sense to do a
lexicographical compare on bool and tristate values though.
Documentation/kbuild/kconfig-language.txt states that expression can have
a value of 'n', 'm' or 'y' (or 0, 1, 2 respectively for calculations).
Let's make it so for relational comparisons with bool/tristate
expressions as well and document them. If at least one symbol is an
actual string then the lexicographical compare works just as before.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu
Pull RCU updates from Paul E. McKenney:
- Updates to use cond_resched() instead of cond_resched_rcu_qs()
where feasible (currently everywhere except in kernel/rcu and
in kernel/torture.c). Also a couple of fixes to avoid sending
IPIs to offline CPUs.
- Updates to simplify RCU's dyntick-idle handling.
- Updates to remove almost all uses of smp_read_barrier_depends()
and read_barrier_depends().
- Miscellaneous fixes.
- Torture-test updates.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
We want the fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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 <rdunlap@infradead.org>
Acked-and-Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <markus.heiser@darmarit.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <markus.heiser@darmarit.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <mchehab@s-opensource.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
This adds the base SoundWire bus type, bus and driver registration.
along with changes to module device table for new SoundWire
device type.
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Acked-By: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Pull in a minimal set of v4.15 entry code changes, for a base for the MM isolation patches.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
zconf.lex.c is generated by flex, zconf.tab.c by bison. Instead of
running flex and bison during the kernel building, we conventionally
version-control those artifacts with _shipped suffix.
It is tedious to manually regenerate them every time we change the
real sources, zconf.l and zconf.y.
Remove the _shipped files and switch over to build-time generation
of the intermediate C files.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
In Linux build system convention, pre-generated files are version-
controlled with a "_shipped" suffix. During the kernel building,
they are simply shipped (copied) removing the suffix.
This approach can reduce external tool dependency for the kernel build,
but it is tedious to manually regenerate such artifacts from developers'
point of view. (We need to do "make REGENERATE_PARSERS=1" every time
we touch real source files such as *.l, *.y)
Some months ago, I sent out RFC patches to run flex, bison, and gperf
during the build.
In the review and test, Linus noticed gperf-3.1 had changed the lookup
function prototype. Then, the use of gperf in kernel was entirely
removed by commit bb3290d91695 ("Remove gperf usage from toolchain").
This time, I tested several versions of flex and bison, and I was not
hit by any compatibility issue except a flaw in flex-2.6.3; if you
generate lexer for dtc and genksyms with flex-2.6.3, you will see
"yywrap redefined" warning. This was not intentional, but a bug,
fixed by flex-2.6.4. Otherwise, both flex and bison look fairly
stable for a long time.
This commit prepares some build rules to remove the _shipped files.
Also, document minimal requirement for flex and bison.
Rationale for the minimal version:
The -Wmissing-prototypes option of GCC warns "no previous prototype"
for lexers generated by flex-2.5.34 or older, so I chose 2.5.35 as the
required version for flex. Flex-2.5.35 was released in 2008. Bison
looks more stable. I did not see any problem with bison-2.0, released
in 2004. I did not test bison-1.x, but bison-2.0 should be old enough.
Tested flex versions:
2.5.35
2.5.36
2.5.37
2.5.39
2.6.0
2.6.1
2.6.2
2.6.3 (*)
2.6.4
(*) flex-2.6.3 causes "yywrap redefined" warning
Tested bison versions:
2.0
2.1
2.2
2.3
2.4
2.4.1
2.5.1
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.6.5
2.7
2.7.1
3.0
3.0.1
3.0.2
3.0.3
3.0.4
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Allow users to use their favorite lexer / parser generators.
This is useful for me to test various flex and bison versions.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Commit 1c199f2878f6 ("kbuild: document recursive dependency limitation
/ resolution") probably intended to show a hint along with "recursive
dependency detected!" error, but it missed to add {...} guard, and the
hint is displayed in every loop of the dep_stack traverse, annoyingly.
This error was detected by GCC's -Wmisleading-indentation when switching
to build-time generation of lexer/parser.
scripts/kconfig/symbol.c: In function ‘sym_check_print_recursive’:
scripts/kconfig/symbol.c:1150:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
if (stack->sym == last_sym)
^~
scripts/kconfig/symbol.c:1153:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
fprintf(stderr, "For a resolution refer to Documentation/kbuild/kconfig-language.txt\n");
^~~~~~~
I could simply add {...} to surround the three fprintf(), but I rather
chose to move the hint after the loop to make the whole message readable.
Fixes: 1c199f2878f6 ("kbuild: document recursive dependency limitation / resolution"
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking fixes from Ingo Molnar:
"Misc fixes:
- Fix a S390 boot hang that was caused by the lock-break logic.
Remove lock-break to begin with, as review suggested it was
unreasonably fragile and our confidence in its continued good
health is lower than our confidence in its removal.
- Remove the lockdep cross-release checking code for now, because of
unresolved false positive warnings. This should make lockdep work
well everywhere again.
- Get rid of the final (and single) ACCESS_ONCE() straggler and
remove the API from v4.15.
- Fix a liblockdep build warning"
* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tools/lib/lockdep: Add missing declaration of 'pr_cont()'
checkpatch: Remove ACCESS_ONCE() warning
compiler.h: Remove ACCESS_ONCE()
tools/include: Remove ACCESS_ONCE()
tools/perf: Convert ACCESS_ONCE() to READ_ONCE()
locking/lockdep: Remove the cross-release locking checks
locking/core: Remove break_lock field when CONFIG_GENERIC_LOCKBREAK=y
locking/core: Fix deadlock during boot on systems with GENERIC_LOCKBREAK
|
|
faddr2line hit var unbound error when CROSS_COMPILE isn't set since
nounset option is set in bash script.
Link: http://lkml.kernel.org/r/20171206013022.GA83929@sofia
Fixes: 95a879825419 ("scripts/faddr2line: extend usage on generic arch")
Signed-off-by: Liu Changcheng <changcheng.liu@intel.com>
Reported-by: Richard Weinberger <richard.weinberger@gmail.com>
Reviewed-by: Richard Weinberger <richard@nod.at>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Kconfig currently doesn't handle 'm' appearing in a Kconfig file before
the modules symbol is defined (the symbol with 'option modules'). The
problem is the following code, which runs during parsing:
/* change 'm' into 'm' && MODULES */
if (e->left.sym == &symbol_mod)
return expr_alloc_and(e, expr_alloc_symbol(modules_sym));
If the modules symbol has not yet been defined, modules_sym is NULL,
giving an invalid expression.
Here is a test file where both BEFORE_1 and BEFORE_2 trigger a segfault.
If the modules symbol is removed, all symbols trigger segfaults.
config BEFORE_1
def_tristate y if m
if m
config BEFORE_2
def_tristate y
endif
config MODULES
def_bool y
option modules
config AFTER_1
def_tristate y if m
if m
config AFTER_2
def_tristate y
endif
Fix the issue by rewriting 'm' in menu_finalize() instead. This function
runs after parsing and is the proper place to do it. The following
existing code in conf_parse() in zconf.y ensures that the modules symbol
exists at that point:
if (!modules_sym)
modules_sym = sym_find( "n" );
...
menu_finalize(&rootmenu);
The following tests were done to ensure no functional changes for
configurations that don't reference 'm' before the modules symbol:
- zconfdump(stdout) was run with ARCH=x86 and ARCH=arm before
and after the change and verified to produce identical output.
This function prints all symbols, choices, and menus together
with their properties and their dependency expressions. A
rewritten 'm' appears as 'm && MODULES'.
A small annoyance is that the assert(len != 0) in xfwrite()
needs to be disabled in order to use zconfdump(), because it
chokes on e.g. 'default ""'.
- The Kconfiglib test suite was run to indirectly verify that
alldefconfig, allyesconfig, allnoconfig, and all defconfigs in
the kernel still generate the same final .config.
- Valgrind was used to check for memory errors and (new) memory
leaks.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
menu_finalize() is one of the more opaque parts of Kconfig, and I need
to make some changes to it to fix an issue related to modules. Add some
comments related to expression rewriting and dependency propagation as a
review aid. They will also help other people trying to understand the
code.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
More directly describes the only thing it does.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
We do not support out-of-tree building of rpm-pkg / deb-pkg. If O=
is given, the build should be terminated, but the "false" command is
not effective since it is not the last command in the cmd_src_tar.
Then, rpm-pkg / deb-pkg tries to continue building, and fails for a
different reason.
Set -e option so that the "false" terminates the building immediately.
I also put the error messages to stderr, and made it stand out more.
For example, "make O=foo rpm-pkg" will fail as follows:
/bin/bash ../scripts/package/mkspec >./kernel.spec
TAR kernel-4.15.0_rc2+.tar.gz
ERROR:
Building source tarball is not possible outside the
kernel source tree. Don't set KBUILD_OUTPUT, or use the
binrpm-pkg or bindeb-pkg target instead.
../scripts/package/Makefile:53: recipe for target 'rpm-pkg' failed
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Jim Davis <jim.epost@gmail.com>
|
