linux/arch/blackfin/Kconfig.debug

259 lines
8.8 KiB
Plaintext
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
# SPDX-License-Identifier: GPL-2.0
menu "Kernel hacking"
source "lib/Kconfig.debug"
config DEBUG_VERBOSE
bool "Verbose fault messages"
default y
select PRINTK
help
When a program crashes due to an exception, or the kernel detects
an internal error, the kernel can print a not so brief message
explaining what the problem was. This debugging information is
useful to developers and kernel hackers when tracking down problems,
but mostly meaningless to other people. This is always helpful for
debugging but serves no purpose on a production system.
Most people should say N here.
config DEBUG_MMRS
tristate "Generate Blackfin MMR tree"
pinctrl: adi2: Fix Kconfig build problem The build robot is complaining on Blackfin: drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup': >> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing pointer to incomplete type 'struct gpio_port_t' writew(readw(&regs->port_fer) & ~BIT(offset), ^~ drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq': >> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing pointer to incomplete type 'struct bfin_pint_regs' if (readl(&regs->invert_set) & pintbit) ^~ It seems the driver need to include <asm/gpio.h> and <asm/irq.h> to compile. The Blackfin architecture was re-defining the Kconfig PINCTRL symbol which is not OK, so replaced this with PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2 just like most arches do. Further, the old GPIO driver symbol GPIO_ADI was possible to select at the same time as selecting PINCTRL. This was not working because the arch-local <asm/gpio.h> header contains an explicit #ifndef PINCTRL clause making compilation break if you combine them. The same is true for DEBUG_MMRS. Make sure the ADI2 pinctrl driver is not selected at the same time as the old GPIO implementation. (This should be converted to use gpiolib or pincontrol and move to drivers/...) Also make sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at the same time as the new PINCTRL implementation, and only make PINCTRL_ADI2 selectable for the Blackfin families that actually have it. This way it is still possible to add e.g. I2C-based pin control expanders on the Blackfin. Cc: Steven Miao <realmz6@gmail.com> Cc: Huanhuan Feng <huanhuan.feng@analog.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-11 09:57:15 +00:00
depends on !PINCTRL
select DEBUG_FS
help
Create a tree of Blackfin MMRs via the debugfs tree. If
you enable this, you will find all MMRs laid out in the
/sys/kernel/debug/blackfin/ directory where you can read/write
MMRs directly from userspace. This is obviously just a debug
feature.
config DEBUG_HWERR
bool "Hardware error interrupt debugging"
depends on DEBUG_KERNEL
help
When enabled, the hardware error interrupt is never disabled, and
will happen immediately when an error condition occurs. This comes
at a slight cost in code size, but is necessary if you are getting
hardware error interrupts and need to know where they are coming
from.
Blackfin: make deferred hardware errors more exact Hardware errors on the Blackfin architecture are queued by nature of the hardware design. Things that could generate a hardware level queue up at the system interface and might not process until much later, at which point the system would send a notification back to the core. As such, it is possible for user space code to do something that would trigger a hardware error, but have it delay long enough for the process context to switch. So when the hardware error does signal, we mistakenly evaluate it as a different process or as kernel context and panic (erp!). This makes it pretty difficult to find the offending context. But wait, there is good news somewhere. By forcing a SSYNC in the interrupt entry, we force all pending queues at the system level to be processed and all hardware errors to be signaled. Then we check the current interrupt state to see if the hardware error is now signaled. If so, we re-queue the current interrupt and return thus allowing the higher priority hardware error interrupt to process properly. Since we haven't done any other context processing yet, the right context will be selected and killed. There is still the possibility that the exact offending instruction will be unknown, but at least we'll have a much better idea of where to look. The downside of course is that this causes system-wide syncs at every interrupt point which results in significant performance degradation. Since this situation should not occur in any properly configured system (as hardware errors are triggered by things like bad pointers), make it a debug configuration option and disable it by default. Signed-off-by: Robin Getz <robin.getz@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-05-18 18:33:26 +00:00
config EXACT_HWERR
bool "Try to make Hardware errors exact"
depends on DEBUG_HWERR
help
By default, the Blackfin hardware errors are not exact - the error
be reported multiple cycles after the error happens. This delay
can cause the wrong application, or even the kernel to receive a
signal to be killed. If you are getting HW errors in your system,
try turning this on to ensure they are at least coming from the
Blackfin: make deferred hardware errors more exact Hardware errors on the Blackfin architecture are queued by nature of the hardware design. Things that could generate a hardware level queue up at the system interface and might not process until much later, at which point the system would send a notification back to the core. As such, it is possible for user space code to do something that would trigger a hardware error, but have it delay long enough for the process context to switch. So when the hardware error does signal, we mistakenly evaluate it as a different process or as kernel context and panic (erp!). This makes it pretty difficult to find the offending context. But wait, there is good news somewhere. By forcing a SSYNC in the interrupt entry, we force all pending queues at the system level to be processed and all hardware errors to be signaled. Then we check the current interrupt state to see if the hardware error is now signaled. If so, we re-queue the current interrupt and return thus allowing the higher priority hardware error interrupt to process properly. Since we haven't done any other context processing yet, the right context will be selected and killed. There is still the possibility that the exact offending instruction will be unknown, but at least we'll have a much better idea of where to look. The downside of course is that this causes system-wide syncs at every interrupt point which results in significant performance degradation. Since this situation should not occur in any properly configured system (as hardware errors are triggered by things like bad pointers), make it a debug configuration option and disable it by default. Signed-off-by: Robin Getz <robin.getz@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-05-18 18:33:26 +00:00
proper thread.
On production systems, it is safe (and a small optimization) to say N.
config DEBUG_DOUBLEFAULT
bool "Debug Double Faults"
default n
help
If an exception is caused while executing code within the exception
handler, the NMI handler, the reset vector, or in emulator mode,
a double fault occurs. On the Blackfin, this is a unrecoverable
event. You have two options:
- RESET exactly when double fault occurs. The excepting
instruction address is stored in RETX, where the next kernel
boot will print it out.
- Print debug message. This is much more error prone, although
easier to handle. It is error prone since:
- The excepting instruction is not committed.
- All writebacks from the instruction are prevented.
- The generated exception is not taken.
- The EXCAUSE field is updated with an unrecoverable event
The only way to check this is to see if EXCAUSE contains the
unrecoverable event value at every exception return. By selecting
this option, you are skipping over the faulting instruction, and
hoping things stay together enough to print out a debug message.
This does add a little kernel code, but is the only method to debug
double faults - if unsure say "Y"
choice
prompt "Double Fault Failure Method"
default DEBUG_DOUBLEFAULT_PRINT
depends on DEBUG_DOUBLEFAULT
config DEBUG_DOUBLEFAULT_PRINT
bool "Print"
config DEBUG_DOUBLEFAULT_RESET
bool "Reset"
endchoice
config DEBUG_HUNT_FOR_ZERO
bool "Catch NULL pointer reads/writes"
default y
help
Say Y here to catch reads/writes to anywhere in the memory range
from 0x0000 - 0x0FFF (the first 4k) of memory. This is useful in
catching common programming errors such as NULL pointer dereferences.
Misbehaving applications will be killed (generate a SEGV) while the
kernel will trigger a panic.
Enabling this option will take up an extra entry in CPLB table.
Otherwise, there is no extra overhead.
config DEBUG_BFIN_HWTRACE_ON
bool "Turn on Blackfin's Hardware Trace"
default y
help
All Blackfins include a Trace Unit which stores a history of the last
16 changes in program flow taken by the program sequencer. The history
allows the user to recreate the program sequencers recent path. This
can be handy when an application dies - we print out the execution
path of how it got to the offending instruction.
By turning this off, you may save a tiny amount of power.
choice
prompt "Omit loop Tracing"
default DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
depends on DEBUG_BFIN_HWTRACE_ON
help
The trace buffer can be configured to omit recording of changes in
program flow that match either the last entry or one of the last
two entries. Omitting one of these entries from the record prevents
the trace buffer from overflowing because of any sort of loop (for, do
while, etc) in the program.
Because zero-overhead Hardware loops are not recorded in the trace buffer,
this feature can be used to prevent trace overflow from loops that
are nested four deep.
config DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
bool "Trace all Loops"
help
The trace buffer records all changes of flow
config DEBUG_BFIN_HWTRACE_COMPRESSION_ONE
bool "Compress single-level loops"
help
The trace buffer does not record single loops - helpful if trace
is spinning on a while or do loop.
config DEBUG_BFIN_HWTRACE_COMPRESSION_TWO
bool "Compress two-level loops"
help
The trace buffer does not record loops two levels deep. Helpful if
the trace is spinning in a nested loop
endchoice
config DEBUG_BFIN_HWTRACE_COMPRESSION
int
depends on DEBUG_BFIN_HWTRACE_ON
default 0 if DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
default 1 if DEBUG_BFIN_HWTRACE_COMPRESSION_ONE
default 2 if DEBUG_BFIN_HWTRACE_COMPRESSION_TWO
config DEBUG_BFIN_HWTRACE_EXPAND
bool "Expand Trace Buffer greater than 16 entries"
depends on DEBUG_BFIN_HWTRACE_ON
default n
help
By selecting this option, every time the 16 hardware entries in
the Blackfin's HW Trace buffer are full, the kernel will move them
into a software buffer, for dumping when there is an issue. This
has a great impact on performance, (an interrupt every 16 change of
flows) and should normally be turned off, except in those nasty
debugging sessions
config DEBUG_BFIN_HWTRACE_EXPAND_LEN
int "Size of Trace buffer (in power of 2k)"
range 0 4
depends on DEBUG_BFIN_HWTRACE_EXPAND
default 1
help
This sets the size of the software buffer that the trace information
is kept in.
0 for (2^0) 1k, or 256 entries,
1 for (2^1) 2k, or 512 entries,
2 for (2^2) 4k, or 1024 entries,
3 for (2^3) 8k, or 2048 entries,
4 for (2^4) 16k, or 4096 entries
config DEBUG_BFIN_NO_KERN_HWTRACE
bool "Turn off hwtrace in CPLB handlers"
depends on DEBUG_BFIN_HWTRACE_ON
default y
help
The CPLB error handler contains a lot of flow changes which can
quickly fill up the hardware trace buffer. When debugging crashes,
the hardware trace may indicate that the problem lies in kernel
space when in reality an application is buggy.
Say Y here to disable hardware tracing in some known "jumpy" pieces
of code so that the trace buffer will extend further back.
config EARLY_PRINTK
bool "Early printk"
default n
select SERIAL_CORE_CONSOLE
help
This option enables special console drivers which allow the kernel
to print messages very early in the bootup process.
This is useful for kernel debugging when your machine crashes very
early before the console code is initialized. After enabling this
feature, you must add "earlyprintk=serial,uart0,57600" to the
command line (bootargs). It is safe to say Y here in all cases, as
all of this lives in the init section and is thrown away after the
kernel boots completely.
config NMI_WATCHDOG
bool "Enable NMI watchdog to help debugging lockup on SMP"
default n
depends on SMP
help
If any CPU in the system does not execute the period local timer
interrupt for more than 5 seconds, then the NMI handler dumps debug
information. This information can be used to debug the lockup.
config CPLB_INFO
bool "Display the CPLB information"
help
Display the CPLB information via /proc/cplbinfo.
config ACCESS_CHECK
bool "Check the user pointer address"
default y
help
Usually the pointer transfer from user space is checked to see if its
address is in the kernel space.
Say N here to disable that check to improve the performance.
config BFIN_ISRAM_SELF_TEST
bool "isram boot self tests"
default n
help
Run some self tests of the isram driver code at boot.
config BFIN_PSEUDODBG_INSNS
bool "Support pseudo debug instructions"
default n
help
This option allows the kernel to emulate some pseudo instructions which
allow simulator test cases to be run under Linux with no changes.
Most people should say N here.
config BFIN_PM_WAKEUP_TIME_BENCH
bool "Display the total time for kernel to resume from power saving mode"
default n
help
Display the total time when kernel resumes normal from standby or
suspend to mem mode.
endmenu