hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge 5.2-rc3 into usb-next 

we want the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Greg Kroah-Hartman 2019-06-03 07:25:25 +02:00
parent 086ebf92aa f2c7c76c5d
commit 119a7fdfee
13450 changed files with 20089 additions and 92089 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
CREDITS
View File

@ -3364,6 +3364,14 @@ S: Braunschweiger Strasse 79
S: 31134 Hildesheim
S: Germany
N: Martin Schwidefsky
D: Martin was the most significant contributor to the initial s390
D: port of the Linux Kernel and later the maintainer of the s390
D: architecture backend for almost two decades.
D: He passed away in 2019, and will be greatly missed.
S: Germany
W: https://lwn.net/Articles/789028/
N: Marcel Selhorst
E: tpmdd@selhorst.net
D: TPM driver

29
Documentation/ABI/testing/sysfs-bus-mdio
View File

@ -1,29 +0,0 @@
What: /sys/bus/mdio_bus/devices/.../phy_id
Date: November 2012
KernelVersion: 3.8
Contact: netdev@vger.kernel.org
Description:
This attribute contains the 32-bit PHY Identifier as reported
by the device during bus enumeration, encoded in hexadecimal.
This ID is used to match the device with the appropriate
driver.
What: /sys/bus/mdio_bus/devices/.../phy_interface
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
This attribute contains the PHY interface as configured by the
Ethernet driver during bus enumeration, encoded in string.
This interface mode is used to configure the Ethernet MAC with the
appropriate mode for its data lines to the PHY hardware.
What: /sys/bus/mdio_bus/devices/.../phy_has_fixups
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
This attribute contains the boolean value whether a given PHY
device has had any "fixup" workaround running on it, encoded as
a boolean. This information is provided to help troubleshooting
PHY configurations.

19
Documentation/ABI/testing/sysfs-class-net-phydev
View File

@ -11,24 +11,31 @@ Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
Boolean value indicating whether the PHY device has
any fixups registered against it (phy_register_fixup)
This attribute contains the boolean value whether a given PHY
device has had any "fixup" workaround running on it, encoded as
a boolean. This information is provided to help troubleshooting
PHY configurations.
What: /sys/class/mdio_bus/<bus>/<device>/phy_id
Date: November 2012
KernelVersion: 3.8
Contact: netdev@vger.kernel.org
Description:
32-bit hexadecimal value corresponding to the PHY device's OUI,
model and revision number.
This attribute contains the 32-bit PHY Identifier as reported
by the device during bus enumeration, encoded in hexadecimal.
This ID is used to match the device with the appropriate
driver.
What: /sys/class/mdio_bus/<bus>/<device>/phy_interface
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
String value indicating the PHY interface, possible
values are:.
This attribute contains the PHY interface as configured by the
Ethernet driver during bus enumeration, encoded in string.
This interface mode is used to configure the Ethernet MAC with the
appropriate mode for its data lines to the PHY hardware.
Possible values are:
<empty> (not available), mii, gmii, sgmii, tbi, rev-mii,
rmii, rgmii, rgmii-id, rgmii-rxid, rgmii-txid, rtbi, smii
xgmii, moca, qsgmii, trgmii, 1000base-x, 2500base-x, rxaui,

9
Documentation/admin-guide/cgroup-v2.rst
View File

@ -177,6 +177,15 @@ cgroup v2 currently supports the following mount options.
ignored on non-init namespace mounts. Please refer to the
Delegation section for details.
memory_localevents
Only populate memory.events with data for the current cgroup,
and not any subtrees. This is legacy behaviour, the default
behaviour without this option is to include subtree counts.
This option is system wide and can only be set on mount or
modified through remount from the init namespace. The mount
option is ignored on non-init namespace mounts.
Organizing Processes and Threads
--------------------------------

1
Documentation/admin-guide/mm/index.rst
View File

@ -31,6 +31,7 @@ the Linux memory management.
ksm
memory-hotplug
numa_memory_policy
numaperf
pagemap
soft-dirty
transhuge

2
Documentation/admin-guide/mm/numaperf.rst
View File

@ -15,7 +15,7 @@ characteristics. Some memory may share the same node as a CPU, and others
are provided as memory only nodes. While memory only nodes do not provide
CPUs, they may still be local to one or more compute nodes relative to
other nodes. The following diagram shows one such example of two compute
nodes with local memory and a memory only node for each of compute node:
nodes with local memory and a memory only node for each of compute node::
+------------------+ +------------------+
| Compute Node 0 +-----+ Compute Node 1 |

9
Documentation/arm64/silicon-errata.txt
View File

@ -58,13 +58,14 @@ stable kernels.
| ARM | Cortex-A72 | #853709 | N/A |
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
| ARM | Cortex-A76 | #1188873 | ARM64_ERRATUM_1188873 |
| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
| ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
| ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 |
| ARM | Neoverse-N1 | #1188873 | ARM64_ERRATUM_1188873 |
| ARM | MMU-500 | #841119,#826419 | N/A |
| ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 |
| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
| ARM | MMU-500 | #841119,826419 | N/A |
| | | | |
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
| Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 |
| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |

2
Documentation/bpf/btf.rst
View File

@ -131,7 +131,7 @@ The following sections detail encoding of each kind.
``btf_type`` is followed by a ``u32`` with the following bits arrangement::
#define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f000000) >> 24)
#define BTF_INT_OFFSET(VAL) (((VAL & 0x00ff0000)) >> 16)
#define BTF_INT_OFFSET(VAL) (((VAL) & 0x00ff0000) >> 16)
#define BTF_INT_BITS(VAL) ((VAL) & 0x000000ff)
The ``BTF_INT_ENCODING`` has the following attributes::

2
Documentation/conf.py
View File

@ -37,7 +37,7 @@ needs_sphinx = '1.3'
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure', 'sphinx.ext.ifconfig']
# The name of the math extension changed on Sphinx 1.4
if major == 1 and minor > 3:
if (major == 1 and minor > 3) or (major > 1):
extensions.append("sphinx.ext.imgmath")
else:
extensions.append("sphinx.ext.pngmath")

2
Documentation/devicetree/bindings/Makefile
View File

@ -5,7 +5,7 @@ DT_MK_SCHEMA ?= dt-mk-schema
DT_MK_SCHEMA_FLAGS := $(if $(DT_SCHEMA_FILES), -u)
quiet_cmd_chk_binding = CHKDT $(patsubst $(srctree)/%,%,$<)
cmd_chk_binding = $(DT_DOC_CHECKER) $< ; \
cmd_chk_binding = $(DT_DOC_CHECKER) -u $(srctree)/$(src) $< ; \
$(DT_EXTRACT_EX) $< > $@
$(obj)/%.example.dts: $(src)/%.yaml FORCE

4
Documentation/devicetree/bindings/arm/arm-boards
View File

@ -216,7 +216,7 @@ Example:
#size-cells = <0>;
A57_0: cpu@0 {
compatible = "arm,cortex-a57","arm,armv8";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
device_type = "cpu";
enable-method = "psci";
@ -225,7 +225,7 @@ Example:
.....
A53_0: cpu@100 {
compatible = "arm,cortex-a53","arm,armv8";
compatible = "arm,cortex-a53";
reg = <0x0 0x100>;
device_type = "cpu";
enable-method = "psci";

12
Documentation/devicetree/bindings/arm/cpu-capacity.txt
View File

@ -118,7 +118,7 @@ cpus {
};
A57_0: cpu@0 {
compatible = "arm,cortex-a57","arm,armv8";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
device_type = "cpu";
enable-method = "psci";
@ -129,7 +129,7 @@ cpus {
};
A57_1: cpu@1 {
compatible = "arm,cortex-a57","arm,armv8";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
device_type = "cpu";
enable-method = "psci";
@ -140,7 +140,7 @@ cpus {
};
A53_0: cpu@100 {
compatible = "arm,cortex-a53","arm,armv8";
compatible = "arm,cortex-a53";
reg = <0x0 0x100>;
device_type = "cpu";
enable-method = "psci";
@ -151,7 +151,7 @@ cpus {
};
A53_1: cpu@101 {
compatible = "arm,cortex-a53","arm,armv8";
compatible = "arm,cortex-a53";
reg = <0x0 0x101>;
device_type = "cpu";
enable-method = "psci";
@ -162,7 +162,7 @@ cpus {
};
A53_2: cpu@102 {
compatible = "arm,cortex-a53","arm,armv8";
compatible = "arm,cortex-a53";
reg = <0x0 0x102>;
device_type = "cpu";
enable-method = "psci";
@ -173,7 +173,7 @@ cpus {
};
A53_3: cpu@103 {
compatible = "arm,cortex-a53","arm,armv8";
compatible = "arm,cortex-a53";
reg = <0x0 0x103>;
device_type = "cpu";
enable-method = "psci";

2
Documentation/devicetree/bindings/arm/omap/crossbar.txt
View File

@ -41,7 +41,7 @@ Examples:
Consumer:
========
See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt for
Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml for
further details.
An interrupt consumer on an SoC using crossbar will use:

2
Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt
View File

@ -35,7 +35,7 @@ board device tree, including the system base clock, as selected by XOM[0]
pin of the SoC. Refer to generic fixed rate clock bindings
documentation[1] for more information how to specify these clocks.
[1] Documentation/devicetree/bindings/clock/fixed-clock.txt
[1] Documentation/devicetree/bindings/clock/fixed-clock.yaml
Example: Clock controller node:

24
Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
View File

@ -92,6 +92,8 @@ properties:
minItems: 2
maxItems: 4
ranges: true
interrupts:
description: Interrupt source of the parent interrupt controller on
secondary GICs, or VGIC maintenance interrupt on primary GIC (see
@ -197,28 +199,28 @@ examples:
interrupt-controller@e1101000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
#address-cells = <1>;
#size-cells = <1>;
interrupt-controller;
interrupts = <1 8 0xf04>;
ranges = <0 0 0 0xe1100000 0 0x100000>;
reg = <0x0 0xe1110000 0 0x01000>,
<0x0 0xe112f000 0 0x02000>,
<0x0 0xe1140000 0 0x10000>,
<0x0 0xe1160000 0 0x10000>;
ranges = <0 0xe1100000 0x100000>;
reg = <0xe1110000 0x01000>,
<0xe112f000 0x02000>,
<0xe1140000 0x10000>,
<0xe1160000 0x10000>;
v2m0: v2m@8000 {
v2m0: v2m@80000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x80000 0 0x1000>;
reg = <0x80000 0x1000>;
};
//...
v2mN: v2m@9000 {
v2mN: v2m@90000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x90000 0 0x1000>;
reg = <0x90000 0x1000>;
};
};
...

2
Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
View File

@ -23,7 +23,7 @@ Required properties:
- marvell,spi-base : List of GIC base SPI interrupts, one for each
ODMI frame. Those SPI interrupts are 0-based,
i.e marvell,spi-base = <128> will use SPI #96.
See Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
See Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
for details about the GIC Device Tree binding.
Example:

2
Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
View File

@ -15,7 +15,7 @@ Optional properties:
- power-supply: specifies the power source. It can either be a regulator
or a gpio which enables a regulator, i.e. a regulator-fixed as
described in
Documentation/devicetree/bindings/regulator/fixed-regulator.txt
Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
Example:

2
Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
View File

@ -24,7 +24,7 @@ Optional children nodes:
Children nodes represent the available nand chips.
Other properties:
see Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
see Documentation/devicetree/bindings/mtd/nand-controller.yaml for generic bindings.
Example demonstrate on AXG SoC:

6
Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
View File

@ -101,12 +101,12 @@ Required properties:
number (e.g., 0, 1, 2, etc.)
- #address-cells : see partition.txt
- #size-cells : see partition.txt
- nand-ecc-strength : see nand.txt
- nand-ecc-step-size : must be 512 or 1024. See nand.txt
- nand-ecc-strength : see nand-controller.yaml
- nand-ecc-step-size : must be 512 or 1024. See nand-controller.yaml
Optional properties:
- nand-on-flash-bbt : boolean, to enable the on-flash BBT for this
chip-select. See nand.txt
chip-select. See nand-controller.yaml
- brcm,nand-oob-sector-size : integer, to denote the spare area sector size
expected for the ECC layout in use. This size, in
addition to the strength and step-size,

6
Documentation/devicetree/bindings/mtd/denali-nand.txt
View File

@ -22,16 +22,16 @@ Sub-nodes:
select is connected.
Optional properties:
- nand-ecc-step-size: see nand.txt for details.
- nand-ecc-step-size: see nand-controller.yaml for details.
If present, the value must be
512 for "altr,socfpga-denali-nand"
1024 for "socionext,uniphier-denali-nand-v5a"
1024 for "socionext,uniphier-denali-nand-v5b"
- nand-ecc-strength: see nand.txt for details. Valid values are:
- nand-ecc-strength: see nand-controller.yaml for details. Valid values are:
8, 15 for "altr,socfpga-denali-nand"
8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
8, 16 for "socionext,uniphier-denali-nand-v5b"
- nand-ecc-maximize: see nand.txt for details
- nand-ecc-maximize: see nand-controller.yaml for details
The chip nodes may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.

6
Documentation/devicetree/bindings/mtd/fsmc-nand.txt
View File

@ -30,9 +30,9 @@ Optional properties:
command is asserted. Zero means one cycle, 255 means 256
cycles.
- bank: default NAND bank to use (0-3 are valid, 0 is the default).
- nand-ecc-mode : see nand.txt
- nand-ecc-strength : see nand.txt
- nand-ecc-step-size : see nand.txt
- nand-ecc-mode : see nand-controller.yaml
- nand-ecc-strength : see nand-controller.yaml
- nand-ecc-step-size : see nand-controller.yaml
Can support 1-bit HW ECC (default) or if stronger correction is required,
software-based BCH.

2
Documentation/devicetree/bindings/mtd/gpmc-nand.txt
View File

@ -8,7 +8,7 @@ explained in a separate documents - please refer to
Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
For NAND specific properties such as ECC modes or bus width, please refer to
Documentation/devicetree/bindings/mtd/nand.txt
Documentation/devicetree/bindings/mtd/nand-controller.yaml
Required properties:

2
Documentation/devicetree/bindings/mtd/hisi504-nand.txt
View File

@ -7,7 +7,7 @@ Required properties:
NAND controller's registers. The second contains base
physical address and size of NAND controller's buffer.
- interrupts: Interrupt number for nfc.
- nand-bus-width: See nand.txt.
- nand-bus-width: See nand-controller.yaml.
- nand-ecc-mode: Support none and hw ecc mode.
- #address-cells: Partition address, should be set 1.
- #size-cells: Partition size, should be set 1.

14
Documentation/devicetree/bindings/mtd/marvell-nand.txt
View File

@ -36,29 +36,29 @@ Children nodes represent the available NAND chips.
Required properties:
- reg: shall contain the native Chip Select ids (0-3).
- nand-rb: see nand.txt (0-1).
- nand-rb: see nand-controller.yaml (0-1).
Optional properties:
- marvell,nand-keep-config: orders the driver not to take the timings
from the core and leaving them completely untouched. Bootloader
timings will then be used.
- label: MTD name.
- nand-on-flash-bbt: see nand.txt.
- nand-ecc-mode: see nand.txt. Will use hardware ECC if not specified.
- nand-ecc-algo: see nand.txt. This property is essentially useful when
- nand-on-flash-bbt: see nand-controller.yaml.
- nand-ecc-mode: see nand-controller.yaml. Will use hardware ECC if not specified.
- nand-ecc-algo: see nand-controller.yaml. This property is essentially useful when
not using hardware ECC. Howerver, it may be added when using hardware
ECC for clarification but will be ignored by the driver because ECC
mode is chosen depending on the page size and the strength required by
the NAND chip. This value may be overwritten with nand-ecc-strength
property.
- nand-ecc-strength: see nand.txt.
- nand-ecc-step-size: see nand.txt. Marvell's NAND flash controller does
- nand-ecc-strength: see nand-controller.yaml.
- nand-ecc-step-size: see nand-controller.yaml. Marvell's NAND flash controller does
use fixed strength (1-bit for Hamming, 16-bit for BCH), so the actual
step size will shrink or grow in order to fit the required strength.
Step sizes are not completely random for all and follow certain
patterns described in AN-379, "Marvell SoC NFC ECC".
See Documentation/devicetree/bindings/mtd/nand.txt for more details on
See Documentation/devicetree/bindings/mtd/nand-controller.yaml for more details on
generic bindings.

6
Documentation/devicetree/bindings/mtd/mxc-nand.txt
View File

@ -4,9 +4,9 @@ Required properties:
- compatible: "fsl,imxXX-nand"
- reg: address range of the nfc block
- interrupts: irq to be used
- nand-bus-width: see nand.txt
- nand-ecc-mode: see nand.txt
- nand-on-flash-bbt: see nand.txt
- nand-bus-width: see nand-controller.yaml
- nand-ecc-mode: see nand-controller.yaml
- nand-on-flash-bbt: see nand-controller.yaml
Example:

6
Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
View File

@ -26,14 +26,14 @@ Optional children node properties:
"hw" is supported.
- nand-ecc-algo: string, algorithm of NAND ECC.
Supported values with "hw" ECC mode are: "rs", "bch".
- nand-bus-width : See nand.txt
- nand-on-flash-bbt: See nand.txt
- nand-bus-width : See nand-controller.yaml
- nand-on-flash-bbt: See nand-controller.yaml
- nand-ecc-strength: integer representing the number of bits to correct
per ECC step (always 512). Supported strength using HW ECC
modes are:
- RS: 4, 6, 8
- BCH: 4, 8, 14, 16
- nand-ecc-maximize: See nand.txt
- nand-ecc-maximize: See nand-controller.yaml
- nand-is-boot-medium: Makes sure only ECC strengths supported by the boot ROM
are chosen.
- wp-gpios: GPIO specifier for the write protect pin.

2
Documentation/devicetree/bindings/mtd/oxnas-nand.txt
View File

@ -1,6 +1,6 @@
* Oxford Semiconductor OXNAS NAND Controller
Please refer to nand.txt for generic information regarding MTD NAND bindings.
Please refer to nand-controller.yaml for generic information regarding MTD NAND bindings.
Required properties:
- compatible: "oxsemi,ox820-nand"

4
Documentation/devicetree/bindings/mtd/qcom_nandc.txt
View File

@ -47,8 +47,8 @@ Required properties:
- #size-cells: see partition.txt
Optional properties:
- nand-bus-width: see nand.txt
- nand-ecc-strength: see nand.txt. If not specified, then ECC strength will
- nand-bus-width: see nand-controller.yaml
- nand-ecc-strength: see nand-controller.yaml. If not specified, then ECC strength will
be used according to chip requirement and available
OOB size.

6
Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
View File

@ -6,7 +6,7 @@ Required properties:
"samsung,s3c2412-nand"
"samsung,s3c2440-nand"
- reg : register's location and length.
- #address-cells, #size-cells : see nand.txt
- #address-cells, #size-cells : see nand-controller.yaml
- clocks : phandle to the nand controller clock
- clock-names : must contain "nand"
@ -14,8 +14,8 @@ Optional child nodes:
Child nodes representing the available nand chips.
Optional child properties:
- nand-ecc-mode : see nand.txt
- nand-on-flash-bbt : see nand.txt
- nand-ecc-mode : see nand-controller.yaml
- nand-on-flash-bbt : see nand-controller.yaml
Each child device node may optionally contain a 'partitions' sub-node,
which further contains sub-nodes describing the flash partition mapping.

6
Documentation/devicetree/bindings/mtd/stm32-fmc2-nand.txt
View File

@ -24,9 +24,9 @@ Required properties:
- reg: describes the CS lines assigned to the NAND device.
Optional properties:
- nand-on-flash-bbt: see nand.txt
- nand-ecc-strength: see nand.txt
- nand-ecc-step-size: see nand.txt
- nand-on-flash-bbt: see nand-controller.yaml
- nand-ecc-strength: see nand-controller.yaml
- nand-ecc-step-size: see nand-controller.yaml
The following ECC strength and step size are currently supported:
- nand-ecc-strength = <1>, nand-ecc-step-size = <512> (Hamming)

2
Documentation/devicetree/bindings/mtd/tango-nand.txt
View File

@ -11,7 +11,7 @@ Required properties:
- #size-cells: <0>
Children nodes represent the available NAND chips.
See Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
See Documentation/devicetree/bindings/mtd/nand-controller.yaml for generic bindings.
Example:

8
Documentation/devicetree/bindings/mtd/vf610-nfc.txt
View File

@ -25,14 +25,14 @@ only handle one NAND chip.
Required properties:
- compatible: Should be set to "fsl,vf610-nfc-cs".
- nand-bus-width: see nand.txt
- nand-ecc-mode: see nand.txt
- nand-bus-width: see nand-controller.yaml
- nand-ecc-mode: see nand-controller.yaml
Required properties for hardware ECC:
- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand-controller.yaml)
- nand-ecc-step-size: step size equals page size, currently only 2k pages are
supported
- nand-on-flash-bbt: see nand.txt
- nand-on-flash-bbt: see nand-controller.yaml
Example:

38
Documentation/devicetree/bindings/sifive/sifive-blocks-ip-versioning.txt Normal file
View File

@ -0,0 +1,38 @@
DT compatible string versioning for SiFive open-source IP blocks
This document describes the version specification for DT "compatible"
strings for open-source SiFive IP blocks. HDL for these IP blocks
can be found in this public repository:
https://github.com/sifive/sifive-blocks
IP block-specific DT compatible strings are contained within the HDL,
in the form "sifive,<ip-block-name><integer version number>".
An example is "sifive,uart0" from:
https://github.com/sifive/sifive-blocks/blob/v1.0/src/main/scala/devices/uart/UART.scala#L43
Until these IP blocks (or IP integration) support version
auto-discovery, the maintainers of these IP blocks intend to increment
the suffixed number in the compatible string whenever the software
interface to these IP blocks changes, or when the functionality of the
underlying IP blocks changes in a way that software should be aware of.
Driver developers can use compatible string "match" values such as
"sifive,uart0" to indicate that their driver is compatible with the
register interface and functionality associated with the relevant
upstream sifive-blocks commits. It is expected that most drivers will
match on these IP block-specific compatible strings.
DT data authors, when writing data for a particular SoC, should
continue to specify an SoC-specific compatible string value, such as
"sifive,fu540-c000-uart". This way, if SoC-specific
integration-specific bug fixes or workarounds are needed, the kernel
or other system software can match on this string to apply them. The
IP block-specific compatible string (such as "sifive,uart0") should
then be specified as a subsequent value.
An example of this style:
compatible = "sifive,fu540-c000-uart", "sifive,uart0";

2
Documentation/driver-api/generic-counter.rst
View File

@ -251,7 +251,7 @@ for defining a counter device.
.. kernel-doc:: include/linux/counter.h
:internal:
.. kernel-doc:: drivers/counter/generic-counter.c
.. kernel-doc:: drivers/counter/counter.c
:export:
Implementation

2
Documentation/firmware-guide/acpi/enumeration.rst
View File

@ -423,7 +423,7 @@ will be enumerated to depends on the device ID returned by _HID.
For example, the following ACPI sample might be used to enumerate an lm75-type
I2C temperature sensor and match it to the driver using the Device Tree
namespace link:
namespace link::
Device (TMP0)
{

14
Documentation/kbuild/makefiles.txt
View File

@ -437,20 +437,6 @@ more details, with real examples.
The second argument is optional, and if supplied will be used
if first argument is not supported.
cc-ldoption
cc-ldoption is used to check if $(CC) when used to link object files
supports the given option. An optional second option may be
specified if first option are not supported.
Example:
#arch/x86/kernel/Makefile
vsyscall-flags += $(call cc-ldoption, -Wl$(comma)--hash-style=sysv)
In the above example, vsyscall-flags will be assigned the option
-Wl$(comma)--hash-style=sysv if it is supported by $(CC).
The second argument is optional, and if supplied will be used
if first argument is not supported.
as-instr
as-instr checks if the assembler reports a specific instruction
and then outputs either option1 or option2

2
Documentation/kdump/kdump.txt
View File

@ -410,7 +410,7 @@ Notes on loading the dump-capture kernel:
* Boot parameter "1" boots the dump-capture kernel into single-user
mode without networking. If you want networking, use "3".
* We generally don' have to bring up a SMP kernel just to capture the
* We generally don't have to bring up a SMP kernel just to capture the
dump. Hence generally it is useful either to build a UP dump-capture
kernel or specify maxcpus=1 option while loading dump-capture kernel.
Note, though maxcpus always works, you had better replace it with

30
Documentation/networking/device_drivers/index.rst Normal file
View File

@ -0,0 +1,30 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Vendor Device Drivers
=====================
Contents:
.. toctree::
:maxdepth: 2
freescale/dpaa2/index
intel/e100
intel/e1000
intel/e1000e
intel/fm10k
intel/igb
intel/igbvf
intel/ixgb
intel/ixgbe
intel/ixgbevf
intel/i40e
intel/iavf
intel/ice
.. only:: subproject
Indices
=======
* :ref:`genindex`

16
Documentation/networking/index.rst
View File

@ -11,19 +11,7 @@ Contents:
batman-adv
can
can_ucan_protocol
device_drivers/freescale/dpaa2/index
device_drivers/intel/e100
device_drivers/intel/e1000
device_drivers/intel/e1000e
device_drivers/intel/fm10k
device_drivers/intel/igb
device_drivers/intel/igbvf
device_drivers/intel/ixgb
device_drivers/intel/ixgbe
device_drivers/intel/ixgbevf
device_drivers/intel/i40e
device_drivers/intel/iavf
device_drivers/intel/ice
device_drivers/index
dsa/index
devlink-info-versions
ieee802154
@ -40,6 +28,8 @@ Contents:
checksum-offloads
segmentation-offloads
scaling
tls
tls-offload
.. only:: subproject

4
Documentation/networking/ip-sysctl.txt
View File

@ -560,10 +560,10 @@ tcp_comp_sack_delay_ns - LONG INTEGER
Default : 1,000,000 ns (1 ms)
tcp_comp_sack_nr - INTEGER
Max numer of SACK that can be compressed.
Max number of SACK that can be compressed.
Using 0 disables SACK compression.
Detault : 44
Default : 44
tcp_slow_start_after_idle - BOOLEAN
If set, provide RFC2861 behavior and time out the congestion

4
Documentation/networking/segmentation-offloads.rst
View File

@ -18,7 +18,7 @@ The following technologies are described:
* Generic Segmentation Offload - GSO
* Generic Receive Offload - GRO
* Partial Generic Segmentation Offload - GSO_PARTIAL
* SCTP accelleration with GSO - GSO_BY_FRAGS
* SCTP acceleration with GSO - GSO_BY_FRAGS
TCP Segmentation Offload
@ -148,7 +148,7 @@ that the IPv4 ID field is incremented in the case that a given header does
not have the DF bit set.
SCTP accelleration with GSO
SCTP acceleration with GSO
===========================
SCTP - despite the lack of hardware support - can still take advantage of

1
Documentation/networking/tls-offload-layers.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 49 KiB

1
Documentation/networking/tls-offload-reorder-bad.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 6.4 KiB

1
Documentation/networking/tls-offload-reorder-good.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 6.4 KiB

482
Documentation/networking/tls-offload.rst Normal file
View File

@ -0,0 +1,482 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
==================
Kernel TLS offload
==================
Kernel TLS operation
====================
Linux kernel provides TLS connection offload infrastructure. Once a TCP
connection is in ``ESTABLISHED`` state user space can enable the TLS Upper
Layer Protocol (ULP) and install the cryptographic connection state.
For details regarding the user-facing interface refer to the TLS
documentation in :ref:`Documentation/networking/tls.rst <kernel_tls>`.
``ktls`` can operate in three modes:
* Software crypto mode (``TLS_SW``) - CPU handles the cryptography.
In most basic cases only crypto operations synchronous with the CPU
can be used, but depending on calling context CPU may utilize
asynchronous crypto accelerators. The use of accelerators introduces extra
latency on socket reads (decryption only starts when a read syscall
is made) and additional I/O load on the system.
* Packet-based NIC offload mode (``TLS_HW``) - the NIC handles crypto
on a packet by packet basis, provided the packets arrive in order.
This mode integrates best with the kernel stack and is described in detail
in the remaining part of this document
(``ethtool`` flags ``tls-hw-tx-offload`` and ``tls-hw-rx-offload``).
* Full TCP NIC offload mode (``TLS_HW_RECORD``) - mode of operation where
NIC driver and firmware replace the kernel networking stack
with its own TCP handling, it is not usable in production environments
making use of the Linux networking stack for example any firewalling
abilities or QoS and packet scheduling (``ethtool`` flag ``tls-hw-record``).
The operation mode is selected automatically based on device configuration,
offload opt-in or opt-out on per-connection basis is not currently supported.
TX
--
At a high level user write requests are turned into a scatter list, the TLS ULP
intercepts them, inserts record framing, performs encryption (in ``TLS_SW``
mode) and then hands the modified scatter list to the TCP layer. From this
point on the TCP stack proceeds as normal.
In ``TLS_HW`` mode the encryption is not performed in the TLS ULP.
Instead packets reach a device driver, the driver will mark the packets
for crypto offload based on the socket the packet is attached to,
and send them to the device for encryption and transmission.
RX
--
On the receive side if the device handled decryption and authentication
successfully, the driver will set the decrypted bit in the associated
:c:type:`struct sk_buff <sk_buff>`. The packets reach the TCP stack and
are handled normally. ``ktls`` is informed when data is queued to the socket
and the ``strparser`` mechanism is used to delineate the records. Upon read
request, records are retrieved from the socket and passed to decryption routine.
If device decrypted all the segments of the record the decryption is skipped,
otherwise software path handles decryption.
.. kernel-figure:: tls-offload-layers.svg
:alt: TLS offload layers
:align: center
:figwidth: 28em
Layers of Kernel TLS stack
Device configuration
====================
During driver initialization device sets the ``NETIF_F_HW_TLS_RX`` and
``NETIF_F_HW_TLS_TX`` features and installs its
:c:type:`struct tlsdev_ops <tlsdev_ops>`
pointer in the :c:member:`tlsdev_ops` member of the
:c:type:`struct net_device <net_device>`.
When TLS cryptographic connection state is installed on a ``ktls`` socket
(note that it is done twice, once for RX and once for TX direction,
and the two are completely independent), the kernel checks if the underlying
network device is offload-capable and attempts the offload. In case offload
fails the connection is handled entirely in software using the same mechanism
as if the offload was never tried.
Offload request is performed via the :c:member:`tls_dev_add` callback of
:c:type:`struct tlsdev_ops <tlsdev_ops>`:
.. code-block:: c
int (*tls_dev_add)(struct net_device *netdev, struct sock *sk,
enum tls_offload_ctx_dir direction,
struct tls_crypto_info *crypto_info,
u32 start_offload_tcp_sn);
``direction`` indicates whether the cryptographic information is for
the received or transmitted packets. Driver uses the ``sk`` parameter
to retrieve the connection 5-tuple and socket family (IPv4 vs IPv6).
Cryptographic information in ``crypto_info`` includes the key, iv, salt
as well as TLS record sequence number. ``start_offload_tcp_sn`` indicates
which TCP sequence number corresponds to the beginning of the record with
sequence number from ``crypto_info``. The driver can add its state
at the end of kernel structures (see :c:member:`driver_state` members
in ``include/net/tls.h``) to avoid additional allocations and pointer
dereferences.
TX
--
After TX state is installed, the stack guarantees that the first segment
of the stream will start exactly at the ``start_offload_tcp_sn`` sequence
number, simplifying TCP sequence number matching.
TX offload being fully initialized does not imply that all segments passing
through the driver and which belong to the offloaded socket will be after
the expected sequence number and will have kernel record information.
In particular, already encrypted data may have been queued to the socket
before installing the connection state in the kernel.
RX
--
In RX direction local networking stack has little control over the segmentation,
so the initial records' TCP sequence number may be anywhere inside the segment.
Normal operation
================
At the minimum the device maintains the following state for each connection, in
each direction:
* crypto secrets (key, iv, salt)
* crypto processing state (partial blocks, partial authentication tag, etc.)
* record metadata (sequence number, processing offset and length)
* expected TCP sequence number
There are no guarantees on record length or record segmentation. In particular
segments may start at any point of a record and contain any number of records.
Assuming segments are received in order, the device should be able to perform
crypto operations and authentication regardless of segmentation. For this
to be possible device has to keep small amount of segment-to-segment state.
This includes at least:
* partial headers (if a segment carried only a part of the TLS header)
* partial data block
* partial authentication tag (all data had been seen but part of the
authentication tag has to be written or read from the subsequent segment)
Record reassembly is not necessary for TLS offload. If the packets arrive
in order the device should be able to handle them separately and make
forward progress.
TX
--
The kernel stack performs record framing reserving space for the authentication
tag and populating all other TLS header and tailer fields.
Both the device and the driver maintain expected TCP sequence numbers
due to the possibility of retransmissions and the lack of software fallback
once the packet reaches the device.
For segments passed in order, the driver marks the packets with
a connection identifier (note that a 5-tuple lookup is insufficient to identify
packets requiring HW offload, see the :ref:`5tuple_problems` section)
and hands them to the device. The device identifies the packet as requiring
TLS handling and confirms the sequence number matches its expectation.
The device performs encryption and authentication of the record data.
It replaces the authentication tag and TCP checksum with correct values.
RX
--
Before a packet is DMAed to the host (but after NIC's embedded switching
and packet transformation functions) the device validates the Layer 4
checksum and performs a 5-tuple lookup to find any TLS connection the packet
may belong to (technically a 4-tuple
lookup is sufficient - IP addresses and TCP port numbers, as the protocol
is always TCP). If connection is matched device confirms if the TCP sequence
number is the expected one and proceeds to TLS handling (record delineation,
decryption, authentication for each record in the packet). The device leaves
the record framing unmodified, the stack takes care of record decapsulation.
Device indicates successful handling of TLS offload in the per-packet context
(descriptor) passed to the host.
Upon reception of a TLS offloaded packet, the driver sets
the :c:member:`decrypted` mark in :c:type:`struct sk_buff <sk_buff>`
corresponding to the segment. Networking stack makes sure decrypted
and non-decrypted segments do not get coalesced (e.g. by GRO or socket layer)
and takes care of partial decryption.
Resync handling
===============
In presence of packet drops or network packet reordering, the device may lose
synchronization with the TLS stream, and require a resync with the kernel's
TCP stack.
Note that resync is only attempted for connections which were successfully
added to the device table and are in TLS_HW mode. For example,
if the table was full when cryptographic state was installed in the kernel,
such connection will never get offloaded. Therefore the resync request
does not carry any cryptographic connection state.
TX
--
Segments transmitted from an offloaded socket can get out of sync
in similar ways to the receive side-retransmissions - local drops
are possible, though network reorders are not.
Whenever an out of order segment is transmitted the driver provides
the device with enough information to perform cryptographic operations.
This means most likely that the part of the record preceding the current
segment has to be passed to the device as part of the packet context,
together with its TCP sequence number and TLS record number. The device
can then initialize its crypto state, process and discard the preceding
data (to be able to insert the authentication tag) and move onto handling
the actual packet.
In this mode depending on the implementation the driver can either ask
for a continuation with the crypto state and the new sequence number
(next expected segment is the one after the out of order one), or continue
with the previous stream state - assuming that the out of order segment
was just a retransmission. The former is simpler, and does not require
retransmission detection therefore it is the recommended method until
such time it is proven inefficient.
RX
--
A small amount of RX reorder events may not require a full resynchronization.
In particular the device should not lose synchronization
when record boundary can be recovered:
.. kernel-figure:: tls-offload-reorder-good.svg
:alt: reorder of non-header segment
:align: center
Reorder of non-header segment
Green segments are successfully decrypted, blue ones are passed
as received on wire, red stripes mark start of new records.
In above case segment 1 is received and decrypted successfully.
Segment 2 was dropped so 3 arrives out of order. The device knows
the next record starts inside 3, based on record length in segment 1.
Segment 3 is passed untouched, because due to lack of data from segment 2
the remainder of the previous record inside segment 3 cannot be handled.
The device can, however, collect the authentication algorithm's state
and partial block from the new record in segment 3 and when 4 and 5
arrive continue decryption. Finally when 2 arrives it's completely outside
of expected window of the device so it's passed as is without special
handling. ``ktls`` software fallback handles the decryption of record
spanning segments 1, 2 and 3. The device did not get out of sync,
even though two segments did not get decrypted.
Kernel synchronization may be necessary if the lost segment contained
a record header and arrived after the next record header has already passed:
.. kernel-figure:: tls-offload-reorder-bad.svg
:alt: reorder of header segment
:align: center
Reorder of segment with a TLS header
In this example segment 2 gets dropped, and it contains a record header.
Device can only detect that segment 4 also contains a TLS header
if it knows the length of the previous record from segment 2. In this case
the device will lose synchronization with the stream.
When the device gets out of sync and the stream reaches TCP sequence
numbers more than a max size record past the expected TCP sequence number,
the device starts scanning for a known header pattern. For example
for TLS 1.2 and TLS 1.3 subsequent bytes of value ``0x03 0x03`` occur
in the SSL/TLS version field of the header. Once pattern is matched
the device continues attempting parsing headers at expected locations
(based on the length fields at guessed locations).
Whenever the expected location does not contain a valid header the scan
is restarted.
When the header is matched the device sends a confirmation request
to the kernel, asking if the guessed location is correct (if a TLS record
really starts there), and which record sequence number the given header had.
The kernel confirms the guessed location was correct and tells the device
the record sequence number. Meanwhile, the device had been parsing
and counting all records since the just-confirmed one, it adds the number
of records it had seen to the record number provided by the kernel.
At this point the device is in sync and can resume decryption at next
segment boundary.
In a pathological case the device may latch onto a sequence of matching
headers and never hear back from the kernel (there is no negative
confirmation from the kernel). The implementation may choose to periodically
restart scan. Given how unlikely falsely-matching stream is, however,
periodic restart is not deemed necessary.
Special care has to be taken if the confirmation request is passed
asynchronously to the packet stream and record may get processed
by the kernel before the confirmation request.
Error handling
==============
TX
--
Packets may be redirected or rerouted by the stack to a different
device than the selected TLS offload device. The stack will handle
such condition using the :c:func:`sk_validate_xmit_skb` helper
(TLS offload code installs :c:func:`tls_validate_xmit_skb` at this hook).
Offload maintains information about all records until the data is
fully acknowledged, so if skbs reach the wrong device they can be handled
by software fallback.
Any device TLS offload handling error on the transmission side must result
in the packet being dropped. For example if a packet got out of order
due to a bug in the stack or the device, reached the device and can't
be encrypted such packet must be dropped.
RX
--
If the device encounters any problems with TLS offload on the receive
side it should pass the packet to the host's networking stack as it was
received on the wire.
For example authentication failure for any record in the segment should
result in passing the unmodified packet to the software fallback. This means
packets should not be modified "in place". Splitting segments to handle partial
decryption is not advised. In other words either all records in the packet
had been handled successfully and authenticated or the packet has to be passed
to the host's stack as it was on the wire (recovering original packet in the
driver if device provides precise error is sufficient).
The Linux networking stack does not provide a way of reporting per-packet
decryption and authentication errors, packets with errors must simply not
have the :c:member:`decrypted` mark set.
A packet should also not be handled by the TLS offload if it contains
incorrect checksums.
Performance metrics
===================
TLS offload can be characterized by the following basic metrics:
* max connection count
* connection installation rate
* connection installation latency
* total cryptographic performance
Note that each TCP connection requires a TLS session in both directions,
the performance may be reported treating each direction separately.
Max connection count
--------------------
The number of connections device can support can be exposed via
``devlink resource`` API.
Total cryptographic performance
-------------------------------
Offload performance may depend on segment and record size.
Overload of the cryptographic subsystem of the device should not have
significant performance impact on non-offloaded streams.
Statistics
==========
Following minimum set of TLS-related statistics should be reported
by the driver:
* ``rx_tls_decrypted`` - number of successfully decrypted TLS segments
* ``tx_tls_encrypted`` - number of in-order TLS segments passed to device
for encryption
* ``tx_tls_ooo`` - number of TX packets which were part of a TLS stream
but did not arrive in the expected order
* ``tx_tls_drop_no_sync_data`` - number of TX packets dropped because
they arrived out of order and associated record could not be found
(see also :ref:`pre_tls_data`)
Notable corner cases, exceptions and additional requirements
============================================================
.. _5tuple_problems:
5-tuple matching limitations
----------------------------
The device can only recognize received packets based on the 5-tuple
of the socket. Current ``ktls`` implementation will not offload sockets
routed through software interfaces such as those used for tunneling
or virtual networking. However, many packet transformations performed
by the networking stack (most notably any BPF logic) do not require
any intermediate software device, therefore a 5-tuple match may
consistently miss at the device level. In such cases the device
should still be able to perform TX offload (encryption) and should
fallback cleanly to software decryption (RX).
Out of order
------------
Introducing extra processing in NICs should not cause packets to be
transmitted or received out of order, for example pure ACK packets
should not be reordered with respect to data segments.
Ingress reorder
---------------
A device is permitted to perform packet reordering for consecutive
TCP segments (i.e. placing packets in the correct order) but any form
of additional buffering is disallowed.
Coexistence with standard networking offload features
-----------------------------------------------------
Offloaded ``ktls`` sockets should support standard TCP stack features
transparently. Enabling device TLS offload should not cause any difference
in packets as seen on the wire.
Transport layer transparency
----------------------------
The device should not modify any packet headers for the purpose
of the simplifying TLS offload.
The device should not depend on any packet headers beyond what is strictly
necessary for TLS offload.
Segment drops
-------------
Dropping packets is acceptable only in the event of catastrophic
system errors and should never be used as an error handling mechanism
in cases arising from normal operation. In other words, reliance
on TCP retransmissions to handle corner cases is not acceptable.
TLS device features
-------------------
Drivers should ignore the changes to TLS the device feature flags.
These flags will be acted upon accordingly by the core ``ktls`` code.
TLS device feature flags only control adding of new TLS connection
offloads, old connections will remain active after flags are cleared.
Known bugs
==========
skb_orphan() leaks clear text
-----------------------------
Currently drivers depend on the :c:member:`sk` member of
:c:type:`struct sk_buff <sk_buff>` to identify segments requiring
encryption. Any operation which removes or does not preserve the socket
association such as :c:func:`skb_orphan` or :c:func:`skb_clone`
will cause the driver to miss the packets and lead to clear text leaks.
Redirects leak clear text
-------------------------
In the RX direction, if segment has already been decrypted by the device
and it gets redirected or mirrored - clear text will be transmitted out.
.. _pre_tls_data:
Transmission of pre-TLS data
----------------------------
User can enqueue some already encrypted and framed records before enabling
``ktls`` on the socket. Those records have to get sent as they are. This is
perfectly easy to handle in the software case - such data will be waiting
in the TCP layer, TLS ULP won't see it. In the offloaded case when pre-queued
segment reaches transmission point it appears to be out of order (before the
expected TCP sequence number) and the stack does not have a record information
associated.
All segments without record information cannot, however, be assumed to be
pre-queued data, because a race condition exists between TCP stack queuing
a retransmission, the driver seeing the retransmission and TCP ACK arriving
for the retransmitted data.

44
Documentation/networking/tls.txt → Documentation/networking/tls.rst
View File

@ -1,3 +1,9 @@
.. _kernel_tls:
==========
Kernel TLS
==========
Overview
========
@ -12,6 +18,8 @@ Creating a TLS connection
First create a new TCP socket and set the TLS ULP.
.. code-block:: c
sock = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));
@ -21,6 +29,8 @@ handshake is complete, we have all the parameters required to move the
data-path to the kernel. There is a separate socket option for moving
the transmit and the receive into the kernel.
.. code-block:: c
/* From linux/tls.h */
struct tls_crypto_info {
unsigned short version;
@ -58,6 +68,8 @@ After setting the TLS_TX socket option all application data sent over this
socket is encrypted using TLS and the parameters provided in the socket option.
For example, we can send an encrypted hello world record as follows:
.. code-block:: c
const char *msg = "hello world\n";
send(sock, msg, strlen(msg));
@ -67,6 +79,8 @@ to the encrypted kernel send buffer if possible.
The sendfile system call will send the file's data over TLS records of maximum
length (2^14).
.. code-block:: c
file = open(filename, O_RDONLY);
fstat(file, &stat);
sendfile(sock, file, &offset, stat.st_size);
@ -89,6 +103,8 @@ After setting the TLS_RX socket option, all recv family socket calls
are decrypted using TLS parameters provided. A full TLS record must
be received before decryption can happen.
.. code-block:: c
char buffer[16384];
recv(sock, buffer, 16384);
@ -97,12 +113,12 @@ large enough, and no additional allocations occur. If the userspace
buffer is too small, data is decrypted in the kernel and copied to
userspace.
EINVAL is returned if the TLS version in the received message does not
``EINVAL`` is returned if the TLS version in the received message does not
match the version passed in setsockopt.
EMSGSIZE is returned if the received message is too big.
``EMSGSIZE`` is returned if the received message is too big.
EBADMSG is returned if decryption failed for any other reason.
``EBADMSG`` is returned if decryption failed for any other reason.
Send TLS control messages
-------------------------
@ -113,9 +129,11 @@ These messages can be sent over the socket by providing the TLS record type
via a CMSG. For example the following function sends @data of @length bytes
using a record of type @record_type.
/* send TLS control message using record_type */
.. code-block:: c
/* send TLS control message using record_type */
static int klts_send_ctrl_message(int sock, unsigned char record_type,
void *data, size_t length)
void *data, size_t length)
{
struct msghdr msg = {0};
int cmsg_len = sizeof(record_type);
@ -151,6 +169,8 @@ type passed via cmsg. If no cmsg buffer is provided, an error is
returned if a control message is received. Data messages may be
received without a cmsg buffer set.
.. code-block:: c
char buffer[16384];
char cmsg[CMSG_SPACE(sizeof(unsigned char))];
struct msghdr msg = {0};
@ -186,12 +206,10 @@ Integrating in to userspace TLS library
At a high level, the kernel TLS ULP is a replacement for the record
layer of a userspace TLS library.
A patchset to OpenSSL to use ktls as the record layer is here:
A patchset to OpenSSL to use ktls as the record layer is
`here <https://github.com/Mellanox/openssl/commits/tls_rx2>`_.
https://github.com/Mellanox/openssl/commits/tls_rx2
An example of calling send directly after a handshake using
gnutls. Since it doesn't implement a full record layer, control
messages are not supported:
https://github.com/ktls/af_ktls-tool/commits/RX
`An example <https://github.com/ktls/af_ktls-tool/commits/RX>`_
of calling send directly after a handshake using gnutls.
Since it doesn't implement a full record layer, control
messages are not supported.

44
Documentation/sphinx/kerneldoc.py
View File

@ -37,7 +37,19 @@ import glob
from docutils import nodes, statemachine
from docutils.statemachine import ViewList
from docutils.parsers.rst import directives, Directive
from sphinx.ext.autodoc import AutodocReporter
#
# AutodocReporter is only good up to Sphinx 1.7
#
import sphinx
Use_SSI = sphinx.__version__[:3] >= '1.7'
if Use_SSI:
from sphinx.util.docutils import switch_source_input
else:
from sphinx.ext.autodoc import AutodocReporter
import kernellog
__version__ = '1.0'
@ -90,7 +102,8 @@ class KernelDocDirective(Directive):
cmd += [filename]
try:
env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd)))
kernellog.verbose(env.app,
'calling kernel-doc \'%s\'' % (" ".join(cmd)))
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
out, err = p.communicate()
@ -100,7 +113,8 @@ class KernelDocDirective(Directive):
if p.returncode != 0:
sys.stderr.write(err)
env.app.warn('kernel-doc \'%s\' failed with return code %d' % (" ".join(cmd), p.returncode))
kernellog.warn(env.app,
'kernel-doc \'%s\' failed with return code %d' % (" ".join(cmd), p.returncode))
return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
elif env.config.kerneldoc_verbosity > 0:
sys.stderr.write(err)
@ -121,20 +135,28 @@ class KernelDocDirective(Directive):
lineoffset += 1
node = nodes.section()
buf = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
self.do_parse(result, node)
return node.children
except Exception as e: # pylint: disable=W0703
kernellog.warn(env.app, 'kernel-doc \'%s\' processing failed with: %s' %
(" ".join(cmd), str(e)))
return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
def do_parse(self, result, node):
if Use_SSI:
with switch_source_input(self.state, result):
self.state.nested_parse(result, 0, node, match_titles=1)
else:
save = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
self.state.memo.reporter = AutodocReporter(result, self.state.memo.reporter)
self.state.memo.title_styles, self.state.memo.section_level = [], 0
try:
self.state.nested_parse(result, 0, node, match_titles=1)
finally:
self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf
self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = save
return node.children
except Exception as e: # pylint: disable=W0703
env.app.warn('kernel-doc \'%s\' processing failed with: %s' %
(" ".join(cmd), str(e)))
return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
def setup(app):
app.add_config_value('kerneldoc_bin', None, 'env')

28
Documentation/sphinx/kernellog.py Normal file
View File

@ -0,0 +1,28 @@
# SPDX-License-Identifier: GPL-2.0
#
# Sphinx has deprecated its older logging interface, but the replacement
# only goes back to 1.6. So here's a wrapper layer to keep around for
# as long as we support 1.4.
#
import sphinx
if sphinx.__version__[:3] >= '1.6':
UseLogging = True
from sphinx.util import logging
logger = logging.getLogger('kerneldoc')
else:
UseLogging = False
def warn(app, message):
if UseLogging:
logger.warning(message)
else:
app.warn(message)
def verbose(app, message):
if UseLogging:
logger.verbose(message)
else:
app.verbose(message)

40
Documentation/sphinx/kfigure.py
View File

@ -60,6 +60,8 @@ import sphinx
from sphinx.util.nodes import clean_astext
from six import iteritems
import kernellog
PY3 = sys.version_info[0] == 3
if PY3:
@ -171,20 +173,20 @@ def setupTools(app):
This function is called once, when the builder is initiated.
"""
global dot_cmd, convert_cmd # pylint: disable=W0603
app.verbose("kfigure: check installed tools ...")
kernellog.verbose(app, "kfigure: check installed tools ...")
dot_cmd = which('dot')
convert_cmd = which('convert')
if dot_cmd:
app.verbose("use dot(1) from: " + dot_cmd)
kernellog.verbose(app, "use dot(1) from: " + dot_cmd)
else:
app.warn("dot(1) not found, for better output quality install "
"graphviz from http://www.graphviz.org")
kernellog.warn(app, "dot(1) not found, for better output quality install "
"graphviz from http://www.graphviz.org")
if convert_cmd:
app.verbose("use convert(1) from: " + convert_cmd)
kernellog.verbose(app, "use convert(1) from: " + convert_cmd)
else:
app.warn(
kernellog.warn(app,
"convert(1) not found, for SVG to PDF conversion install "
"ImageMagick (https://www.imagemagick.org)")
@ -220,12 +222,13 @@ def convert_image(img_node, translator, src_fname=None):
# in kernel builds, use 'make SPHINXOPTS=-v' to see verbose messages
app.verbose('assert best format for: ' + img_node['uri'])
kernellog.verbose(app, 'assert best format for: ' + img_node['uri'])
if in_ext == '.dot':
if not dot_cmd:
app.verbose("dot from graphviz not available / include DOT raw.")
kernellog.verbose(app,
"dot from graphviz not available / include DOT raw.")
img_node.replace_self(file2literal(src_fname))
elif translator.builder.format == 'latex':
@ -252,7 +255,8 @@ def convert_image(img_node, translator, src_fname=None):
if translator.builder.format == 'latex':
if convert_cmd is None:
app.verbose("no SVG to PDF conversion available / include SVG raw.")
kernellog.verbose(app,
"no SVG to PDF conversion available / include SVG raw.")
img_node.replace_self(file2literal(src_fname))
else:
dst_fname = path.join(translator.builder.outdir, fname + '.pdf')
@ -265,18 +269,19 @@ def convert_image(img_node, translator, src_fname=None):
_name = dst_fname[len(translator.builder.outdir) + 1:]
if isNewer(dst_fname, src_fname):
app.verbose("convert: {out}/%s already exists and is newer" % _name)
kernellog.verbose(app,
"convert: {out}/%s already exists and is newer" % _name)
else:
ok = False
mkdir(path.dirname(dst_fname))
if in_ext == '.dot':
app.verbose('convert DOT to: {out}/' + _name)
kernellog.verbose(app, 'convert DOT to: {out}/' + _name)
ok = dot2format(app, src_fname, dst_fname)
elif in_ext == '.svg':
app.verbose('convert SVG to: {out}/' + _name)
kernellog.verbose(app, 'convert SVG to: {out}/' + _name)
ok = svg2pdf(app, src_fname, dst_fname)
if not ok:
@ -305,7 +310,8 @@ def dot2format(app, dot_fname, out_fname):
with open(out_fname, "w") as out:
exit_code = subprocess.call(cmd, stdout = out)
if exit_code != 0:
app.warn("Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
kernellog.warn(app,
"Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
return bool(exit_code == 0)
def svg2pdf(app, svg_fname, pdf_fname):
@ -322,7 +328,7 @@ def svg2pdf(app, svg_fname, pdf_fname):
# use stdout and stderr from parent
exit_code = subprocess.call(cmd)
if exit_code != 0:
app.warn("Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
return bool(exit_code == 0)
@ -415,15 +421,15 @@ def visit_kernel_render(self, node):
app = self.builder.app
srclang = node.get('srclang')
app.verbose('visit kernel-render node lang: "%s"' % (srclang))
kernellog.verbose(app, 'visit kernel-render node lang: "%s"' % (srclang))
tmp_ext = RENDER_MARKUP_EXT.get(srclang, None)
if tmp_ext is None:
app.warn('kernel-render: "%s" unknown / include raw.' % (srclang))
kernellog.warn(app, 'kernel-render: "%s" unknown / include raw.' % (srclang))
return
if not dot_cmd and tmp_ext == '.dot':
app.verbose("dot from graphviz not available / include raw.")
kernellog.verbose(app, "dot from graphviz not available / include raw.")
return
literal_block = node[0]

66
Documentation/usb/rio.txt
View File

@ -76,70 +76,30 @@ Additional Information and userspace tools
Requirements
============
A host with a USB port. Ideally, either a UHCI (Intel) or OHCI
(Compaq and others) hardware port should work.
A host with a USB port running a Linux kernel with RIO 500 support enabled.
A Linux development kernel (2.3.x) with USB support enabled or a
backported version to linux-2.2.x. See http://www.linux-usb.org for
more information on accomplishing this.
The driver is a module called rio500, which should be automatically loaded
as you plug in your device. If that fails you can manually load it with
A Linux kernel with RIO 500 support enabled.
modprobe rio500
'lspci' which is only needed to determine the type of USB hardware
available in your machine.
Configuration
Using `lspci -v`, determine the type of USB hardware available.
If you see something like::
USB Controller: ......
Flags: .....
I/O ports at ....
Then you have a UHCI based controller.
If you see something like::
USB Controller: .....
Flags: ....
Memory at .....
Then you have a OHCI based controller.
Using `make menuconfig` or your preferred method for configuring the
kernel, select 'Support for USB', 'OHCI/UHCI' depending on your
hardware (determined from the steps above), 'USB Diamond Rio500 support', and
'Preliminary USB device filesystem'. Compile and install the modules
(you may need to execute `depmod -a` to update the module
dependencies).
Add a device for the USB rio500::
Udev should automatically create a device node as soon as plug in your device.
If that fails, you can manually add a device for the USB rio500::
mknod /dev/usb/rio500 c 180 64
Set appropriate permissions for /dev/usb/rio500 (don't forget about
group and world permissions). Both read and write permissions are
In that case, set appropriate permissions for /dev/usb/rio500 (don't forget
about group and world permissions). Both read and write permissions are
required for proper operation.
Load the appropriate modules (if compiled as modules):
OHCI::
modprobe usbcore
modprobe usb-ohci
modprobe rio500
UHCI::
modprobe usbcore
modprobe usb-uhci (or uhci)
modprobe rio500
That's it. The Rio500 Utils at: http://rio500.sourceforge.net should
be able to access the rio500.
Limits
======
You can use only a single rio500 device at a time with your computer.
Bugs
====

8
Documentation/vm/hmm.rst
View File

@ -288,15 +288,17 @@ For instance if the device flags for device entries are:
WRITE (1 << 62)
Now let say that device driver wants to fault with at least read a range then
it does set:
range->default_flags = (1 << 63)
it does set::
range->default_flags = (1 << 63);
range->pfn_flags_mask = 0;
and calls hmm_range_fault() as described above. This will fill fault all page
in the range with at least read permission.
Now let say driver wants to do the same except for one page in the range for
which its want to have write. Now driver set:
which its want to have write. Now driver set::
range->default_flags = (1 << 63);
range->pfn_flags_mask = (1 << 62);
range->pfns[index_of_write] = (1 << 62);

40
MAINTAINERS
View File

@ -696,6 +696,7 @@ F: drivers/input/mouse/alps.*
ALTERA I2C CONTROLLER DRIVER
M: Thor Thayer <thor.thayer@linux.intel.com>
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-altera.txt
F: drivers/i2c/busses/i2c-altera.c
ALTERA MAILBOX DRIVER
@ -1174,6 +1175,7 @@ S: Maintained
F: Documentation/devicetree/bindings/arm/arm-boards
F: Documentation/devicetree/bindings/auxdisplay/arm-charlcd.txt
F: Documentation/devicetree/bindings/clock/arm-integrator.txt
F: Documentation/devicetree/bindings/i2c/i2c-versatile.txt
F: Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt
F: Documentation/devicetree/bindings/mtd/arm-versatile.txt
F: arch/arm/mach-integrator/
@ -1781,6 +1783,7 @@ ARM/LPC18XX ARCHITECTURE
M: Vladimir Zapolskiy <vz@mleia.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt
F: arch/arm/boot/dts/lpc43*
F: drivers/i2c/busses/i2c-lpc2k.c
F: drivers/memory/pl172.c
@ -1794,6 +1797,7 @@ M: Sylvain Lemieux <slemieux.tyco@gmail.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
T: git git://github.com/vzapolskiy/linux-lpc32xx.git
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-pnx.txt
F: arch/arm/boot/dts/lpc32*
F: arch/arm/mach-lpc32xx/
F: drivers/i2c/busses/i2c-pnx.c
@ -1918,6 +1922,8 @@ ARM/NOMADIK/U300/Ux500 ARCHITECTURES
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-nomadik.txt
F: Documentation/devicetree/bindings/i2c/i2c-stu300.txt
F: arch/arm/mach-nomadik/
F: arch/arm/mach-u300/
F: arch/arm/mach-ux500/
@ -2140,6 +2146,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-rockchip@lists.infradead.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
F: arch/arm/boot/dts/rk3*
F: arch/arm/boot/dts/rv1108*
F: arch/arm/mach-rockchip/
@ -2275,6 +2282,7 @@ M: Patrice Chotard <patrice.chotard@st.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
W: http://www.stlinux.com
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-st.txt
F: arch/arm/mach-sti/
F: arch/arm/boot/dts/sti*
F: drivers/char/hw_random/st-rng.c
@ -2466,6 +2474,7 @@ ARM/VT8500 ARM ARCHITECTURE
M: Tony Prisk <linux@prisktech.co.nz>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-wmt.txt
F: arch/arm/mach-vt8500/
F: drivers/clocksource/timer-vt8500.c
F: drivers/i2c/busses/i2c-wmt.c
@ -2531,6 +2540,8 @@ F: drivers/cpuidle/cpuidle-zynq.c
F: drivers/block/xsysace.c
N: zynq
N: xilinx
F: Documentation/devicetree/bindings/i2c/i2c-cadence.txt
F: Documentation/devicetree/bindings/i2c/i2c-xiic.txt
F: drivers/clocksource/timer-cadence-ttc.c
F: drivers/i2c/busses/i2c-cadence.c
F: drivers/mmc/host/sdhci-of-arasan.c
@ -2627,7 +2638,7 @@ F: Documentation/devicetree/bindings/eeprom/at24.txt
F: drivers/misc/eeprom/at24.c
ATA OVER ETHERNET (AOE) DRIVER
M: "Ed L. Cashin" <ed.cashin@acm.org>
M: "Justin Sanders" <justin@coraid.com>
W: http://www.openaoe.org/
S: Supported
F: Documentation/aoe/
@ -2768,7 +2779,7 @@ AVIA HX711 ANALOG DIGITAL CONVERTER IIO DRIVER
M: Andreas Klinger <ak@it-klinger.de>
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
F: Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
F: drivers/iio/adc/hx711.c
AX.25 NETWORK LAYER
@ -3049,8 +3060,9 @@ S: Maintained
F: arch/riscv/net/
BPF JIT for S390
M: Martin Schwidefsky <schwidefsky@de.ibm.com>
M: Heiko Carstens <heiko.carstens@de.ibm.com>
M: Vasily Gorbik <gor@linux.ibm.com>
M: Christian Borntraeger <borntraeger@de.ibm.com>
L: netdev@vger.kernel.org
L: bpf@vger.kernel.org
S: Maintained
@ -7341,6 +7353,7 @@ I2C MV64XXX MARVELL AND ALLWINNER DRIVER
M: Gregory CLEMENT <gregory.clement@bootlin.com>
L: linux-i2c@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
F: drivers/i2c/busses/i2c-mv64xxx.c
I2C OVER PARALLEL PORT
@ -8611,14 +8624,12 @@ F: arch/x86/include/asm/svm.h
F: arch/x86/kvm/svm.c
KERNEL VIRTUAL MACHINE FOR ARM/ARM64 (KVM/arm, KVM/arm64)
M: Christoffer Dall <christoffer.dall@arm.com>
M: Marc Zyngier <marc.zyngier@arm.com>
R: James Morse <james.morse@arm.com>
R: Julien Thierry <julien.thierry@arm.com>
R: Suzuki K Pouloze <suzuki.poulose@arm.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: kvmarm@lists.cs.columbia.edu
W: http://systems.cs.columbia.edu/projects/kvm-arm
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
S: Maintained
F: arch/arm/include/uapi/asm/kvm*
@ -11068,10 +11079,8 @@ S: Supported
F: drivers/net/ethernet/qlogic/netxen/
NFC SUBSYSTEM
M: Samuel Ortiz <sameo@linux.intel.com>
L: linux-wireless@vger.kernel.org
L: linux-nfc@lists.01.org (subscribers-only)
S: Supported
L: netdev@vger.kernel.org
S: Orphan
F: net/nfc/
F: include/net/nfc/
F: include/uapi/linux/nfc.h
@ -11228,7 +11237,7 @@ F: drivers/video/fbdev/riva/
F: drivers/video/fbdev/nvidia/
NVM EXPRESS DRIVER
M: Keith Busch <keith.busch@intel.com>
M: Keith Busch <kbusch@kernel.org>
M: Jens Axboe <axboe@fb.com>
M: Christoph Hellwig <hch@lst.de>
M: Sagi Grimberg <sagi@grimberg.me>
@ -11728,6 +11737,7 @@ M: Peter Korsgaard <peter@korsgaard.com>
M: Andrew Lunn <andrew@lunn.ch>
L: linux-i2c@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-ocores.txt
F: Documentation/i2c/busses/i2c-ocores
F: drivers/i2c/busses/i2c-ocores.c
F: include/linux/platform_data/i2c-ocores.h
@ -13367,6 +13377,7 @@ F: drivers/clk/renesas/
RENESAS EMEV2 I2C DRIVER
M: Wolfram Sang <wsa+renesas@sang-engineering.com>
S: Supported
F: Documentation/devicetree/bindings/i2c/i2c-emev2.txt
F: drivers/i2c/busses/i2c-emev2.c
RENESAS ETHERNET DRIVERS
@ -13388,6 +13399,8 @@ F: drivers/iio/adc/rcar-gyroadc.c
RENESAS R-CAR I2C DRIVERS
M: Wolfram Sang <wsa+renesas@sang-engineering.com>
S: Supported
F: Documentation/devicetree/bindings/i2c/i2c-rcar.txt
F: Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
F: drivers/i2c/busses/i2c-rcar.c
F: drivers/i2c/busses/i2c-sh_mobile.c
@ -13618,8 +13631,9 @@ S: Maintained
F: drivers/video/fbdev/savage/
S390
M: Martin Schwidefsky <schwidefsky@de.ibm.com>
M: Heiko Carstens <heiko.carstens@de.ibm.com>
M: Vasily Gorbik <gor@linux.ibm.com>
M: Christian Borntraeger <borntraeger@de.ibm.com>
L: linux-s390@vger.kernel.org
W: http://www.ibm.com/developerworks/linux/linux390/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git
@ -14353,7 +14367,7 @@ SIMPLEFB FB DRIVER
M: Hans de Goede <hdegoede@redhat.com>
L: linux-fbdev@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/display/simple-framebuffer.txt
F: Documentation/devicetree/bindings/display/simple-framebuffer.yaml
F: drivers/video/fbdev/simplefb.c
F: include/linux/platform_data/simplefb.h
@ -15676,6 +15690,7 @@ R: Bartosz Golaszewski <bgolaszewski@baylibre.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
T: git git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git
S: Supported
F: Documentation/devicetree/bindings/i2c/i2c-davinci.txt
F: arch/arm/mach-davinci/
F: drivers/i2c/busses/i2c-davinci.c
F: arch/arm/boot/dts/da850*
@ -17379,6 +17394,7 @@ M: Jan Glauber <jglauber@cavium.com>
L: linux-i2c@vger.kernel.org
W: http://www.cavium.com
S: Supported
F: Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt
F: drivers/i2c/busses/i2c-xlp9xx.c
XRA1403 GPIO EXPANDER

4
Makefile
View File

@ -2,8 +2,8 @@
VERSION = 5
PATCHLEVEL = 2
SUBLEVEL = 0
EXTRAVERSION = -rc1
NAME = Shy Crocodile
EXTRAVERSION = -rc3
NAME = Golden Lions
# *DOCUMENTATION*
# To see a list of typical targets execute "make help"

6
arch/alpha/boot/stdio.c
View File

@ -1,10 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright (C) Paul Mackerras 1997.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
#include <stdarg.h>
#include <stddef.h>

10
arch/alpha/include/asm/xor.h
View File

@ -1,16 +1,8 @@
/* SPDX-License-Identifier: GPL-2.0-or-later */
/*
* include/asm-alpha/xor.h
*
* Optimized RAID-5 checksumming functions for alpha EV5 and EV6
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2, or (at your option)
* any later version.
*
* You should have received a copy of the GNU General Public License
* (for example /usr/src/linux/COPYING); if not, write to the Free
* Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
extern void xor_alpha_2(unsigned long, unsigned long *, unsigned long *);

1
arch/alpha/include/uapi/asm/Kbuild
View File

@ -1 +1,2 @@
# SPDX-License-Identifier: GPL-2.0
generated-y += unistd_32.h

14
arch/alpha/kernel/module.c
View File

@ -1,19 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/* Kernel module help for Alpha.
Copyright (C) 2002 Richard Henderson.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include <linux/moduleloader.h>
#include <linux/elf.h>

1
arch/alpha/math-emu/Makefile
View File

@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
#
# Makefile for the FPU instruction emulation.
#

1
arch/alpha/math-emu/math.c
View File

@ -1,3 +1,4 @@
// SPDX-License-Identifier: GPL-2.0-only
#include <linux/module.h>
#include <linux/types.h>
#include <linux/kernel.h>

1
arch/alpha/mm/Makefile
View File

@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
#
# Makefile for the linux alpha-specific parts of the memory manager.
#

1
arch/arc/Kbuild
View File

@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += kernel/
obj-y += mm/

1
arch/arc/include/uapi/asm/Kbuild
View File

@ -1 +1,2 @@
# SPDX-License-Identifier: GPL-2.0
generic-y += ucontext.h

11
arch/arc/plat-axs10x/axs10x.c
View File

@ -1,17 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* AXS101/AXS103 Software Development Platform
*
* Copyright (C) 2013-15 Synopsys, Inc. (www.synopsys.com)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
*/
#include <linux/of_fdt.h>

1
arch/arc/plat-eznps/Makefile
View File

@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
#
# Makefile for the linux kernel.
#

1
arch/arm/boot/compressed/decompress.c
View File

@ -32,6 +32,7 @@
extern char * strstr(const char * s1, const char *s2);
extern size_t strlen(const char *s);
extern int memcmp(const void *cs, const void *ct, size_t count);
extern char * strchrnul(const char *, int);
#ifdef CONFIG_KERNEL_GZIP
#include "../../../../lib/decompress_inflate.c"

3
arch/arm/boot/dts/aks-cdu.dts
View File

@ -1,10 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* aks-cdu.dts - Device Tree file for AK signal CDU
*
* Copyright (C) 2012 AK signal Brno a.s.
* 2012 Jiri Prchal <jiri.prchal@aksignal.cz>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;

3
arch/arm/boot/dts/animeo_ip.dts
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* animeo_ip.dts - Device Tree file for Somfy Animeo IP Boards
*
* Copyright (C) 2011-2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2 only.
*/
/dts-v1/;

3
arch/arm/boot/dts/at91-ariag25.dts
View File

@ -1,10 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-ariag25.dts - Device Tree file for Acme Systems Aria G25 (AT91SAM9G25 based)
*
* Copyright (C) 2013 Douglas Gilbert <dgilbert@interlog.com>,
* Robert Nelson <robertcnelson@gmail.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "at91sam9g25.dtsi"

3
arch/arm/boot/dts/at91-cosino.dtsi
View File

@ -1,3 +1,4 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-cosino.dtsi - Device Tree file for Cosino core module
*
@ -7,8 +8,6 @@
* Derived from at91sam9x5ek.dtsi by:
* Copyright (C) 2012 Atmel,
* 2012 Nicolas Ferre <nicolas.ferre@atmel.com>
*
* Licensed under GPLv2 or later.
*/
#include "at91sam9g35.dtsi"

3
arch/arm/boot/dts/at91-cosino_mega2560.dts
View File

@ -1,3 +1,4 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-cosino_mega2560.dts - Device Tree file for Cosino board with
* Mega 2560 extension
@ -8,8 +9,6 @@
* Derived from at91sam9g35ek.dts by:
* Copyright (C) 2012 Atmel,
* 2012 Nicolas Ferre <nicolas.ferre@atmel.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;

3
arch/arm/boot/dts/at91-foxg20.dts
View File

@ -1,11 +1,10 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-foxg20.dts - Device Tree file for Acme Systems FoxG20 board
*
* Based on DT files for at91sam9g20ek evaluation board (AT91SAM9G20 SoC)
*
* Copyright (C) 2013 Douglas Gilbert <dgilbert@interlog.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "at91sam9g20.dtsi"

3
arch/arm/boot/dts/at91-kizbox.dts
View File

@ -1,10 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-kizbox.dts - Device Tree file for Overkiz Kizbox board
*
* Copyright (C) 2012-2014 Boris BREZILLON <b.brezillon@overkiz.com>
* 2014-2015 Gaël PORTAY <g.portay@overkiz.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "at91sam9g20.dtsi"

3
arch/arm/boot/dts/at91-kizbox2.dts
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-kizbox2.dts - Device Tree file for Overkiz Kizbox 2 board
*
* Copyright (C) 2014 Gaël PORTAY <g.portay@overkiz.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "sama5d31.dtsi"

3
arch/arm/boot/dts/at91-kizboxmini.dts
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-kizboxmini.dts - Device Tree file for Overkiz Kizbox mini board
*
* Copyright (C) 2014 Gaël PORTAY <g.portay@overkiz.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "at91sam9g25.dtsi"

3
arch/arm/boot/dts/at91-linea.dtsi
View File

@ -1,11 +1,10 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
*
* Copyright (C) 2017 Axentia Technologies AB
*
* Author: Peter Rosin <peda@axentia.se>
*
* Licensed under GPLv2 or later.
*/
#include "sama5d31.dtsi"

3
arch/arm/boot/dts/at91-qil_a9260.dts
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91-qil_a9260.dts - Device Tree file for Calao QIL A9260 board
*
* Copyright (C) 2011-2013 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2.
*/
/dts-v1/;
#include "at91sam9260.dtsi"

3
arch/arm/boot/dts/at91-sam9_l9260.dts
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-sam9_l9260.dts - Device Tree file for Olimex SAM9-L9260 board
*
* Copyright (C) 2016 Raashid Muhammed <raashidmuhammed@zilogic.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "at91sam9260.dtsi"

3
arch/arm/boot/dts/at91-sama5d3_xplained.dts
View File

@ -1,10 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-sama5d3_xplained.dts - Device Tree file for the SAMA5D3 Xplained board
*
* Copyright (C) 2014 Atmel,
* 2014 Nicolas Ferre <nicolas.ferre@atmel.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "sama5d36.dtsi"

8
arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi
View File

@ -1,12 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright (C) 2015 Marek Vasut <marex@denx.de>
*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
* Version 2 or later at the following locations:
*
* http://www.opensource.org/licenses/gpl-license.html
* http://www.gnu.org/copyleft/gpl.html
*/
#include "sama5d4.dtsi"

8
arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
View File

@ -1,12 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright (C) 2015 Marek Vasut <marex@denx.de>
*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
* Version 2 or later at the following locations:
*
* http://www.opensource.org/licenses/gpl-license.html
* http://www.gnu.org/copyleft/gpl.html
*/
/dts-v1/;

3
arch/arm/boot/dts/at91-tse850-3.dts
View File

@ -1,11 +1,10 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91-tse850-3.dts - Device Tree file for the Axentia TSE-850 3.0 board
*
* Copyright (C) 2017 Axentia Technologies AB
*
* Author: Peter Rosin <peda@axentia.se>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include <dt-bindings/pwm/pwm.h>

3
arch/arm/boot/dts/at91rm9200.dtsi
View File

@ -1,3 +1,4 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91rm9200.dtsi - Device Tree Include file for AT91RM9200 family SoC
*
@ -6,8 +7,6 @@
* 2012 Joachim Eastwood <manabian@gmail.com>
*
* Based on at91sam9260.dtsi
*
* Licensed under GPLv2 or later.
*/
#include <dt-bindings/pinctrl/at91.h>

3
arch/arm/boot/dts/at91rm9200_pqfp.dtsi
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91rm9200_pqfp.dtsi - Device Tree Include file for AT91RM9200 PQFP family SoC
*
* Copyright (C) 2013 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2 or later.
*/
#include "at91rm9200.dtsi"

3
arch/arm/boot/dts/at91rm9200ek.dts
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91rm9200ek.dts - Device Tree file for Atmel AT91RM9200 evaluation kit
*
* Copyright (C) 2012 Joachim Eastwood <manabian@gmail.com>
*
* Licensed under GPLv2 only
*/
/dts-v1/;
#include "at91rm9200.dtsi"

3
arch/arm/boot/dts/at91sam9260.dtsi
View File

@ -1,11 +1,10 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91sam9260.dtsi - Device Tree Include file for AT91SAM9260 family SoC
*
* Copyright (C) 2011 Atmel,
* 2011 Nicolas Ferre <nicolas.ferre@atmel.com>,
* 2011 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2 or later.
*/
#include <dt-bindings/pinctrl/at91.h>

3
arch/arm/boot/dts/at91sam9261.dtsi
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9261.dtsi - Device Tree Include file for AT91SAM9261 SoC
*
* Copyright (C) 2013 Jean-Jacques Hiblot <jjhiblot@traphandler.com>
*
* Licensed under GPLv2 only.
*/
#include <dt-bindings/pinctrl/at91.h>

3
arch/arm/boot/dts/at91sam9261ek.dts
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9261ek.dts - Device Tree file for Atmel at91sam9261 reference board
*
* Copyright (C) 2013 Jean-Jacques Hiblot <jjhiblot@traphandler.com>
*
* Licensed under GPLv2 only.
*/
/dts-v1/;
#include "at91sam9261.dtsi"

3
arch/arm/boot/dts/at91sam9263.dtsi
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9263.dtsi - Device Tree Include file for AT91SAM9263 family SoC
*
* Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2 only.
*/
#include <dt-bindings/pinctrl/at91.h>

3
arch/arm/boot/dts/at91sam9263ek.dts
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9263ek.dts - Device Tree file for Atmel at91sam9263 reference board
*
* Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2 only
*/
/dts-v1/;
#include "at91sam9263.dtsi"

3
arch/arm/boot/dts/at91sam9g15.dtsi
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9g15.dtsi - Device Tree Include file for AT91SAM9G15 SoC
*
* Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2.
*/
#include "at91sam9x5.dtsi"

3
arch/arm/boot/dts/at91sam9g15ek.dts
View File

@ -1,10 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91sam9g15ek.dts - Device Tree file for AT91SAM9G15-EK board
*
* Copyright (C) 2012 Atmel,
* 2012 Nicolas Ferre <nicolas.ferre@atmel.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "at91sam9g15.dtsi"

3
arch/arm/boot/dts/at91sam9g20.dtsi
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9g20.dtsi - Device Tree Include file for AT91SAM9G20 family SoC
*
* Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2.
*/
#include "at91sam9260.dtsi"

3
arch/arm/boot/dts/at91sam9g20ek.dts
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9g20ek.dts - Device Tree file for Atmel at91sam9g20ek board
*
* Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2.
*/
/dts-v1/;
#include "at91sam9g20ek_common.dtsi"

3
arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9g20ek_2mmc.dts - Device Tree file for Atmel at91sam9g20ek 2 MMC board
*
* Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2.
*/
/dts-v1/;
#include "at91sam9g20ek_common.dtsi"

3
arch/arm/boot/dts/at91sam9g20ek_common.dtsi
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9g20ek_common.dtsi - Device Tree file for Atmel at91sam9g20ek board
*
* Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2.
*/
#include "at91sam9g20.dtsi"

3
arch/arm/boot/dts/at91sam9g25.dtsi
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9g25.dtsi - Device Tree Include file for AT91SAM9G25 SoC
*
* Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2.
*/
#include "at91sam9x5.dtsi"

3
arch/arm/boot/dts/at91sam9g25ek.dts
View File

@ -1,10 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91sam9g25ek.dts - Device Tree file for AT91SAM9G25-EK board
*
* Copyright (C) 2012 Atmel,
* 2012 Nicolas Ferre <nicolas.ferre@atmel.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "at91sam9g25.dtsi"

3
arch/arm/boot/dts/at91sam9g35.dtsi
View File

@ -1,9 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* at91sam9g35.dtsi - Device Tree Include file for AT91SAM9G35 SoC
*
* Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
*
* Licensed under GPLv2.
*/
#include "at91sam9x5.dtsi"

3
arch/arm/boot/dts/at91sam9g35ek.dts
View File

@ -1,10 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91sam9g35ek.dts - Device Tree file for AT91SAM9G35-EK board
*
* Copyright (C) 2012 Atmel,
* 2012 Nicolas Ferre <nicolas.ferre@atmel.com>
*
* Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "at91sam9g35.dtsi"

3
arch/arm/boot/dts/at91sam9g45.dtsi
View File

@ -1,3 +1,4 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at91sam9g45.dtsi - Device Tree Include file for AT91SAM9G45 family SoC
* applies to AT91SAM9G45, AT91SAM9M10,
@ -5,8 +6,6 @@
*
* Copyright (C) 2011 Atmel,
* 2011 Nicolas Ferre <nicolas.ferre@atmel.com>
*
* Licensed under GPLv2 or later.
*/
#include <dt-bindings/dma/at91.h>

Some files were not shown because too many files have changed in this diff Show More