NAND core changes:
- use longest matching pattern in ->exec_op() default parser - export NAND operation tracer - add flag to indicate panic_write in MTD - use kzalloc() instead of kmalloc() and memset() Raw NAND controller drivers changes: - brcmnand: * fix BCH ECC layout for large page NAND parts * fallback to detected ecc-strength, ecc-step-size * when oops in progress use pio and interrupt polling * code refactor code to introduce helper functions * add support for v7.3 controller - FSMC: * use nand_op_trace for operation tracing - GPMI: * move all driver code into single file * various cleanups (including dmaengine changes) * use runtime PM to manage clocks * implement exec_op - MTK: * correct low level time calculation of r/w cycle * improve data sampling timing for read cycle * add validity check for CE# pin setting * fix wrongly assigned OOB buffer pointer issue * re-license MTK NAND driver as Dual MIT/GPL - STM32: * manage the get_irq error case * increase DMA completion timeouts Raw NAND chips drivers changes: - Macronix: add read-retry support Onenand driver changes: - add support for 8Gb datasize chips - avoid fall-through warnings SPI-NAND changes: - define macros for page-read ops with three-byte addresses - add support for two-byte device IDs and then for GigaDevice GD5F1GQ4UFxxG - add initial support for Paragon PN26G0xA - handle the case where the last page read has bitflips -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAl0fxH8ACgkQJWrqGEe9 VoRq5wgApOTmT44UiI3XHQZMWANcW5/DkNwXEzXtdRQJHv1m3eqny1faGOYJZifZ eb0TpohK0783L4STii7g1iplBA+c8UGJaS1bpn9HoN3us8wxXn51fzHHj5G3z2tR xoyaEm7w7dZuqe/FLCW+MbtOREAq1GzullVZxrd75wxNyK3cQXawqYDsil6I5fl7 sf2zMzfzfGK6LqbapOHorxyI8yJR712TLPwBq7amHpPZMXOny0gIlYVXLv6jYAfr 3RcW0YpyplBjLAFKBOpVLPJ61c9NVQSsdQ2wviRckhrMgCD83f7YDmAACxM0rvSz lVYcHHqoqYHlTDPVBebeoifQOb4uUw== =I5Hg -----END PGP SIGNATURE----- Merge tag 'nand/for-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux into mtd/next NAND core changes: - use longest matching pattern in ->exec_op() default parser - export NAND operation tracer - add flag to indicate panic_write in MTD - use kzalloc() instead of kmalloc() and memset() Raw NAND controller drivers changes: - brcmnand: * fix BCH ECC layout for large page NAND parts * fallback to detected ecc-strength, ecc-step-size * when oops in progress use pio and interrupt polling * code refactor code to introduce helper functions * add support for v7.3 controller - FSMC: * use nand_op_trace for operation tracing - GPMI: * move all driver code into single file * various cleanups (including dmaengine changes) * use runtime PM to manage clocks * implement exec_op - MTK: * correct low level time calculation of r/w cycle * improve data sampling timing for read cycle * add validity check for CE# pin setting * fix wrongly assigned OOB buffer pointer issue * re-license MTK NAND driver as Dual MIT/GPL - STM32: * manage the get_irq error case * increase DMA completion timeouts Raw NAND chips drivers changes: - Macronix: add read-retry support Onenand driver changes: - add support for 8Gb datasize chips - avoid fall-through warnings SPI-NAND changes: - define macros for page-read ops with three-byte addresses - add support for two-byte device IDs and then for GigaDevice GD5F1GQ4UFxxG - add initial support for Paragon PN26G0xA - handle the case where the last page read has bitflips
This commit is contained in:
Richard Weinberger
commit
1d2af80d58
8
CREDITS
8
CREDITS
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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
|
||||
--------------------------------
|
||||
|
|
|
|||
|
|
@ -31,6 +31,7 @@ the Linux memory management.
|
|||
ksm
|
||||
memory-hotplug
|
||||
numa_memory_policy
|
||||
numaperf
|
||||
pagemap
|
||||
soft-dirty
|
||||
transhuge
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
|
|
|||
|
|
@ -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")
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -28,6 +28,7 @@ Required properties:
|
|||
brcm,brcmnand-v7.0
|
||||
brcm,brcmnand-v7.1
|
||||
brcm,brcmnand-v7.2
|
||||
brcm,brcmnand-v7.3
|
||||
brcm,brcmnand
|
||||
- reg : the register start and length for NAND register region.
|
||||
(optional) Flash DMA register range (if present)
|
||||
|
|
@ -101,12 +102,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
|
||||
|
||||
Optional properties:
|
||||
- nand-ecc-strength : see nand-controller.yaml
|
||||
- nand-ecc-step-size : must be 512 or 1024. See nand-controller.yaml
|
||||
- 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,
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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,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.
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
{
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 49 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 6.4 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 6.4 KiB |
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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')
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
||||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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
|
||||
====
|
||||
|
||||
|
|
|
|||
|
|
@ -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
40
MAINTAINERS
|
|
@ -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
|
||||
|
|
@ -7349,6 +7361,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
|
||||
|
|
@ -8619,14 +8632,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*
|
||||
|
|
@ -11076,10 +11087,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
|
||||
|
|
@ -11236,7 +11245,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>
|
||||
|
|
@ -11736,6 +11745,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
|
||||
|
|
@ -13375,6 +13385,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
|
||||
|
|
@ -13396,6 +13407,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
|
||||
|
||||
|
|
@ -13626,8 +13639,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
|
||||
|
|
@ -14361,7 +14375,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
|
||||
|
||||
|
|
@ -15684,6 +15698,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*
|
||||
|
|
@ -17387,6 +17402,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
4
Makefile
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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 +1,2 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
generated-y += unistd_32.h
|
||||
|
|
|
|||
|
|
@ -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,3 +1,4 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
#
|
||||
# Makefile for the FPU instruction emulation.
|
||||
#
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
// SPDX-License-Identifier: GPL-2.0-only
|
||||
#include <linux/module.h>
|
||||
#include <linux/types.h>
|
||||
#include <linux/kernel.h>
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
#
|
||||
# Makefile for the linux alpha-specific parts of the memory manager.
|
||||
#
|
||||
|
|
|
|||
|
|
@ -1,2 +1,3 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
obj-y += kernel/
|
||||
obj-y += mm/
|
||||
|
|
|
|||
|
|
@ -1 +1,2 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
generic-y += ucontext.h
|
||||
|
|
|
|||
|
|
@ -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,3 +1,4 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
#
|
||||
# Makefile for the linux kernel.
|
||||
#
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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/;
|
||||
|
|
|
|||
|
|
@ -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/;
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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/;
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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/;
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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
Loading…
Reference in New Issue