AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-11-24 22:40:53 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
b24413180f
linux_dsm_epyc7002/drivers/auxdisplay/Kconfig
Greg Kroah-Hartman b24413180f 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-02 11:10:55 +01:00

450 lines
16 KiB
Plaintext
Raw Blame History

# SPDX-License-Identifier: GPL-2.0
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/kconfig-language.txt.
#
# Auxiliary display drivers configuration.
#
menuconfig AUXDISPLAY
bool "Auxiliary Display support"
---help---
Say Y here to get to see options for auxiliary display drivers.
This option alone does not add any kernel code.
If you say N, all options in this submenu will be skipped and disabled.
config CHARLCD
tristate "Character LCD core support" if COMPILE_TEST
if AUXDISPLAY
config HD44780
tristate "HD44780 Character LCD support"
depends on GPIOLIB || COMPILE_TEST
select CHARLCD
---help---
Enable support for Character LCDs using a HD44780 controller.
The LCD is accessible through the /dev/lcd char device (10, 156).
This code can either be compiled as a module, or linked into the
kernel and started at boot.
If you don't understand what all this is about, say N.
config KS0108
tristate "KS0108 LCD Controller"
depends on PARPORT_PC
default n
---help---
If you have a LCD controlled by one or more KS0108
controllers, say Y. You will need also another more specific
driver for your LCD.
Depends on Parallel Port support. If you say Y at
parport, you will be able to compile this as a module (M)
and built-in as well (Y).
To compile this as a module, choose M here:
the module will be called ks0108.
If unsure, say N.
config KS0108_PORT
hex "Parallel port where the LCD is connected"
depends on KS0108
default 0x378
---help---
The address of the parallel port where the LCD is connected.
The first standard parallel port address is 0x378.
The second standard parallel port address is 0x278.
The third standard parallel port address is 0x3BC.
You can specify a different address if you need.
If you don't know what I'm talking about, load the parport module,
and execute "dmesg" or "cat /proc/ioports". You can see there how
many parallel ports are present and which address each one has.
Usually you only need to use 0x378.
If you compile this as a module, you can still override this
using the module parameters.
config KS0108_DELAY
int "Delay between each control writing (microseconds)"
depends on KS0108
default "2"
---help---
Amount of time the ks0108 should wait between each control write
to the parallel port.
If your LCD seems to miss random writings, increment this.
If you don't know what I'm talking about, ignore it.
If you compile this as a module, you can still override this
value using the module parameters.
config CFAG12864B
tristate "CFAG12864B LCD"
depends on X86
depends on FB
depends on KS0108
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
default n
---help---
If you have a Crystalfontz 128x64 2-color LCD, cfag12864b Series,
say Y. You also need the ks0108 LCD Controller driver.
For help about how to wire your LCD to the parallel port,
check Documentation/auxdisplay/cfag12864b
Depends on the x86 arch and the framebuffer support.
The LCD framebuffer driver can be attached to a console.
It will work fine. However, you can't attach it to the fbdev driver
of the xorg server.
To compile this as a module, choose M here:
the modules will be called cfag12864b and cfag12864bfb.
If unsure, say N.
config CFAG12864B_RATE
int "Refresh rate (hertz)"
depends on CFAG12864B
default "20"
---help---
Refresh rate of the LCD.
As the LCD is not memory mapped, the driver has to make the work by
software. This means you should be careful setting this value higher.
If your CPUs are really slow or you feel the system is slowed down,
decrease the value.
Be careful modifying this value to a very high value:
You can freeze the computer, or the LCD maybe can't draw as fast as you
are requesting.
If you don't know what I'm talking about, ignore it.
If you compile this as a module, you can still override this
value using the module parameters.
config IMG_ASCII_LCD
tristate "Imagination Technologies ASCII LCD Display"
default y if MIPS_MALTA || MIPS_SEAD3
select SYSCON
help
Enable this to support the simple ASCII LCD displays found on
development boards such as the MIPS Boston, MIPS Malta & MIPS SEAD3
from Imagination Technologies.
config HT16K33
tristate "Holtek Ht16K33 LED controller with keyscan"
depends on FB && OF && I2C && INPUT
select FB_SYS_FOPS
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select INPUT_MATRIXKMAP
select FB_BACKLIGHT
help
Say yes here to add support for Holtek HT16K33, RAM mapping 16*8
LED controller driver with keyscan.
endif # AUXDISPLAY
config ARM_CHARLCD
bool "ARM Ltd. Character LCD Driver"
depends on PLAT_VERSATILE
help
This is a driver for the character LCD found on the ARM Ltd.
Versatile and RealView Platform Baseboards. It doesn't do
very much more than display the text "ARM Linux" on the first
line and the Linux version on the second line, but that's
still useful.
config PANEL
tristate "Parallel port LCD/Keypad Panel support"
depends on PARPORT
select CHARLCD
---help---
Say Y here if you have an HD44780 or KS-0074 LCD connected to your
parallel port. This driver also features 4 and 6-key keypads. The LCD
is accessible through the /dev/lcd char device (10, 156), and the
keypad through /dev/keypad (10, 185). This code can either be
compiled as a module, or linked into the kernel and started at boot.
If you don't understand what all this is about, say N.
if PANEL
config PANEL_PARPORT
int "Default parallel port number (0=LPT1)"
range 0 255
default "0"
---help---
This is the index of the parallel port the panel is connected to. One
driver instance only supports one parallel port, so if your keypad
and LCD are connected to two separate ports, you have to start two
modules with different arguments. Numbering starts with '0' for LPT1,
and so on.
config PANEL_PROFILE
int "Default panel profile (0-5, 0=custom)"
range 0 5
default "5"
---help---
To ease configuration, the driver supports different configuration
profiles for past and recent wirings. These profiles can also be
used to define an approximative configuration, completed by a few
other options. Here are the profiles :
0 = custom (see further)
1 = 2x16 parallel LCD, old keypad
2 = 2x16 serial LCD (KS-0074), new keypad
3 = 2x16 parallel LCD (Hantronix), no keypad
4 = 2x16 parallel LCD (Nexcom NSA1045) with Nexcom's keypad
5 = 2x40 parallel LCD (old one), with old keypad
Custom configurations allow you to define how your display is
wired to the parallel port, and how it works. This is only intended
for experts.
config PANEL_KEYPAD
depends on PANEL_PROFILE="0"
int "Keypad type (0=none, 1=old 6 keys, 2=new 6 keys, 3=Nexcom 4 keys)"
range 0 3
default 0
---help---
This enables and configures a keypad connected to the parallel port.
The keys will be read from character device 10,185. Valid values are :
0 : do not enable this driver
1 : old 6 keys keypad
2 : new 6 keys keypad, as used on the server at www.ant-computing.com
3 : Nexcom NSA1045's 4 keys keypad
New profiles can be described in the driver source. The driver also
supports simultaneous keys pressed when the keypad supports them.
config PANEL_LCD
depends on PANEL_PROFILE="0"
int "LCD type (0=none, 1=custom, 2=old //, 3=ks0074, 4=hantronix, 5=Nexcom)"
range 0 5
default 0
---help---
This enables and configures an LCD connected to the parallel port.
The driver includes an interpreter for escape codes starting with
'\e[L' which are specific to the LCD, and a few ANSI codes. The
driver will be registered as character device 10,156, usually
under the name '/dev/lcd'. There are a total of 6 supported types :
0 : do not enable the driver
1 : custom configuration and wiring (see further)
2 : 2x16 & 2x40 parallel LCD (old wiring)
3 : 2x16 serial LCD (KS-0074 based)
4 : 2x16 parallel LCD (Hantronix wiring)
5 : 2x16 parallel LCD (Nexcom wiring)
When type '1' is specified, other options will appear to configure
more precise aspects (wiring, dimensions, protocol, ...). Please note
that those values changed from the 2.4 driver for better consistency.
config PANEL_LCD_HEIGHT
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "Number of lines on the LCD (1-2)"
range 1 2
default 2
---help---
This is the number of visible character lines on the LCD in custom profile.
It can either be 1 or 2.
config PANEL_LCD_WIDTH
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "Number of characters per line on the LCD (1-40)"
range 1 40
default 40
---help---
This is the number of characters per line on the LCD in custom profile.
Common values are 16,20,24,40.
config PANEL_LCD_BWIDTH
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "Internal LCD line width (1-40, 40 by default)"
range 1 40
default 40
---help---
Most LCDs use a standard controller which supports hardware lines of 40
characters, although sometimes only 16, 20 or 24 of them are really wired
to the terminal. This results in some non-visible but addressable characters,
and is the case for most parallel LCDs. Other LCDs, and some serial ones,
however, use the same line width internally as what is visible. The KS0074
for example, uses 16 characters per line for 16 visible characters per line.
This option lets you configure the value used by your LCD in 'custom' profile.
If you don't know, put '40' here.
config PANEL_LCD_HWIDTH
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "Hardware LCD line width (1-64, 64 by default)"
range 1 64
default 64
---help---
Most LCDs use a single address bit to differentiate line 0 and line 1. Since
some of them need to be able to address 40 chars with the lower bits, they
often use the immediately superior power of 2, which is 64, to address the
next line.
If you don't know what your LCD uses, in doubt let 16 here for a 2x16, and
64 here for a 2x40.
config PANEL_LCD_CHARSET
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "LCD character set (0=normal, 1=KS0074)"
range 0 1
default 0
---help---
Some controllers such as the KS0074 use a somewhat strange character set
where many symbols are at unusual places. The driver knows how to map
'standard' ASCII characters to the character sets used by these controllers.
Valid values are :
0 : normal (untranslated) character set
1 : KS0074 character set
If you don't know, use the normal one (0).
config PANEL_LCD_PROTO
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "LCD communication mode (0=parallel 8 bits, 1=serial)"
range 0 1
default 0
---help---
This driver now supports any serial or parallel LCD wired to a parallel
port. But before assigning signals, the driver needs to know if it will
be driving a serial LCD or a parallel one. Serial LCDs only use 2 wires
(SDA/SCL), while parallel ones use 2 or 3 wires for the control signals
(E, RS, sometimes RW), and 4 or 8 for the data. Use 0 here for a 8 bits
parallel LCD, and 1 for a serial LCD.
config PANEL_LCD_PIN_E
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO="0"
int "Parallel port pin number & polarity connected to the LCD E signal (-17...17) "
range -17 17
default 14
---help---
This describes the number of the parallel port pin to which the LCD 'E'
signal has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'E' pin in custom profile is '14' (AUTOFEED).
config PANEL_LCD_PIN_RS
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO="0"
int "Parallel port pin number & polarity connected to the LCD RS signal (-17...17) "
range -17 17
default 17
---help---
This describes the number of the parallel port pin to which the LCD 'RS'
signal has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'RS' pin in custom profile is '17' (SELECT IN).
config PANEL_LCD_PIN_RW
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO="0"
int "Parallel port pin number & polarity connected to the LCD RW signal (-17...17) "
range -17 17
default 16
---help---
This describes the number of the parallel port pin to which the LCD 'RW'
signal has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'RW' pin in custom profile is '16' (INIT).
config PANEL_LCD_PIN_SCL
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO!="0"
int "Parallel port pin number & polarity connected to the LCD SCL signal (-17...17) "
range -17 17
default 1
---help---
This describes the number of the parallel port pin to which the serial
LCD 'SCL' signal has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'SCL' pin in custom profile is '1' (STROBE).
config PANEL_LCD_PIN_SDA
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO!="0"
int "Parallel port pin number & polarity connected to the LCD SDA signal (-17...17) "
range -17 17
default 2
---help---
This describes the number of the parallel port pin to which the serial
LCD 'SDA' signal has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'SDA' pin in custom profile is '2' (D0).
config PANEL_LCD_PIN_BL
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "Parallel port pin number & polarity connected to the LCD backlight signal (-17...17) "
range -17 17
default 0
---help---
This describes the number of the parallel port pin to which the LCD 'BL' signal
has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'BL' pin in custom profile is '0' (uncontrolled).
config PANEL_CHANGE_MESSAGE
bool "Change LCD initialization message ?"
default "n"
---help---
This allows you to replace the boot message indicating the kernel version
and the driver version with a custom message. This is useful on appliances
where a simple 'Starting system' message can be enough to stop a customer
from worrying.
If you say 'Y' here, you'll be able to choose a message yourself. Otherwise,
say 'N' and keep the default message with the version.
config PANEL_BOOT_MESSAGE
depends on PANEL_CHANGE_MESSAGE="y"
string "New initialization message"
default ""
---help---
This allows you to replace the boot message indicating the kernel version
and the driver version with a custom message. This is useful on appliances
where a simple 'Starting system' message can be enough to stop a customer
from worrying.
An empty message will only clear the display at driver init time. Any other
printf()-formatted message is valid with newline and escape codes.
endif # PANEL
Reference in New Issue View Git Blame Copy Permalink