redonkable/remarkable-linux
redonkable/remarkable-linux
1
0
Fork 0
Code Releases Activity

Merge branch 'master' into test

Browse source 
* master: (1190 commits)
  ASoC: stm32: add of dependency for stm32 drivers
  ASoC: mt8173-rt5650: fix child-node lookup
  ASoC: dapm: fix debugfs read using path->connected
  platform/x86: samsung-laptop: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  platform/x86: ideapad-laptop: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  platform/x86: dell-laptop: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  seq_file: Introduce DEFINE_SHOW_ATTRIBUTE() helper macro
  Documentation/sysctl/user.txt: fix typo
  MAINTAINERS: update ARM/QUALCOMM SUPPORT patterns
  MAINTAINERS: update various PALM patterns
  MAINTAINERS: update "ARM/OXNAS platform support" patterns
  MAINTAINERS: update Cortina/Gemini patterns
  MAINTAINERS: remove ARM/CLKDEV SUPPORT file pattern
  MAINTAINERS: remove ANDROID ION pattern
  mm: docs: add blank lines to silence sphinx "Unexpected indentation" errors
  mm: docs: fix parameter names mismatch
  mm: docs: fixup punctuation
  pipe: read buffer limits atomically
  pipe: simplify round_pipe_size()
  pipe: reject F_SETPIPE_SZ with size over UINT_MAX
  ...
This commit is contained in:
Jens Axboe 2018-02-07 15:54:20 -07:00
parent 9e05c86499 581e400ff9
commit 61a695184f
1825 changed files with 43345 additions and 25997 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
Documentation/ABI/testing/sysfs-driver-samsung-laptop
View file

@ -3,7 +3,7 @@ Date: January 1, 2010
KernelVersion: 2.6.33
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description: Some Samsung laptops have different "performance levels"
that are can be modified by a function key, and by this
that can be modified by a function key, and by this
sysfs file. These values don't always make a whole lot
of sense, but some users like to modify them to keep
their fans quiet at all costs. Reading from this file

6
Documentation/admin-guide/kernel-parameters.txt
View file

@ -3711,7 +3711,11 @@
[KNL, SMP] Set scheduler's default relax_domain_level.
See Documentation/cgroup-v1/cpusets.txt.
reserve= [KNL,BUGS] Force the kernel to ignore some iomem area
reserve= [KNL,BUGS] Force kernel to ignore I/O ports or memory
Format: <base1>,<size1>[,<base2>,<size2>,...]
Reserve I/O ports or memory so the kernel won't use
them. If <base> is less than 0x10000, the region
is assumed to be I/O ports; otherwise it is memory.
reservetop= [X86-32]
Format: nn[KMG]

66
Documentation/admin-guide/thunderbolt.rst
View file

@ -3,13 +3,13 @@
=============
The interface presented here is not meant for end users. Instead there
should be a userspace tool that handles all the low-level details, keeps
database of the authorized devices and prompts user for new connections.
a database of the authorized devices and prompts users for new connections.
More details about the sysfs interface for Thunderbolt devices can be
found in ``Documentation/ABI/testing/sysfs-bus-thunderbolt``.
Those users who just want to connect any device without any sort of
manual work, can add following line to
manual work can add following line to
``/etc/udev/rules.d/99-local.rules``::
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0", ATTR{authorized}="1"
@ -20,7 +20,7 @@ vulnerable to DMA attacks.
Security levels and how to use them
-----------------------------------
Starting from Intel Falcon Ridge Thunderbolt controller there are 4
Starting with Intel Falcon Ridge Thunderbolt controller there are 4
security levels available. The reason for these is the fact that the
connected devices can be DMA masters and thus read contents of the host
memory without CPU and OS knowing about it. There are ways to prevent
@ -37,14 +37,14 @@ The security levels are as follows:
user
User is asked whether the device is allowed to be connected.
Based on the device identification information available through
``/sys/bus/thunderbolt/devices``. user then can do the decision.
``/sys/bus/thunderbolt/devices``, the user then can make the decision.
In BIOS settings this is typically called *Unique ID*.
secure
User is asked whether the device is allowed to be connected. In
addition to UUID the device (if it supports secure connect) is sent
a challenge that should match the expected one based on a random key
written to ``key`` sysfs attribute. In BIOS settings this is
written to the ``key`` sysfs attribute. In BIOS settings this is
typically called *One time saved key*.
dponly
@ -78,7 +78,7 @@ When a device is plugged in it will appear in sysfs as follows::
/sys/bus/thunderbolt/devices/0-1/unique_id - e0376f00-0300-0100-ffff-ffffffffffff
The ``authorized`` attribute reads 0 which means no PCIe tunnels are
created yet. The user can authorize the device by simply::
created yet. The user can authorize the device by simply entering::
# echo 1 > /sys/bus/thunderbolt/devices/0-1/authorized
@ -86,7 +86,7 @@ This will create the PCIe tunnels and the device is now connected.
If the device supports secure connect, and the domain security level is
set to ``secure``, it has an additional attribute ``key`` which can hold
a random 32 byte value used for authorization and challenging the device in
a random 32-byte value used for authorization and challenging the device in
future connects::
/sys/bus/thunderbolt/devices/0-3/authorized - 0
@ -99,12 +99,12 @@ future connects::
Notice the key is empty by default.
If the user does not want to use secure connect it can just ``echo 1``
If the user does not want to use secure connect they can just ``echo 1``
to the ``authorized`` attribute and the PCIe tunnels will be created in
the same way than in ``user`` security level.
the same way as in the ``user`` security level.
If the user wants to use secure connect, the first time the device is
plugged a key needs to be created and send to the device::
plugged a key needs to be created and sent to the device::
# key=$(openssl rand -hex 32)
# echo $key > /sys/bus/thunderbolt/devices/0-3/key
@ -121,27 +121,27 @@ device using the same key::
If the challenge the device returns back matches the one we expect based
on the key, the device is connected and the PCIe tunnels are created.
However, if the challenge failed no tunnels are created and error is
However, if the challenge fails no tunnels are created and error is
returned to the user.
If the user still wants to connect the device it can either approve
the device without a key or write new key and write 1 to the
If the user still wants to connect the device they can either approve
the device without a key or write a new key and write 1 to the
``authorized`` file to get the new key stored on the device NVM.
Upgrading NVM on Thunderbolt device or host
-------------------------------------------
Since most of the functionality is handled in a firmware running on a
Since most of the functionality is handled in firmware running on a
host controller or a device, it is important that the firmware can be
upgraded to the latest where possible bugs in it have been fixed.
Typically OEMs provide this firmware from their support site.
There is also a central site which has links where to download firmwares
There is also a central site which has links where to download firmware
for some machines:
`Thunderbolt Updates <https://thunderbolttechnology.net/updates>`_
Before you upgrade firmware on a device or host, please make sure it is
the suitable. Failing to do that may render the device (or host) in a
Before you upgrade firmware on a device or host, please make sure it is a
suitable upgrade. Failing to do that may render the device (or host) in a
state where it cannot be used properly anymore without special tools!
Host NVM upgrade on Apple Macs is not supported.
@ -151,7 +151,7 @@ Thunderbolt device so that the host controller appears. It does not
matter which device is connected (unless you are upgrading NVM on a
device - then you need to connect that particular device).
Note OEM-specific method to power the controller up ("force power") may
Note an OEM-specific method to power the controller up ("force power") may
be available for your system in which case there is no need to plug in a
Thunderbolt device.
@ -171,7 +171,7 @@ it comes back the driver notices it and initiates a full power cycle.
After a while the host controller appears again and this time it should
be fully functional.
We can verify that the new NVM firmware is active by running following
We can verify that the new NVM firmware is active by running the following
commands::
# cat /sys/bus/thunderbolt/devices/0-0/nvm_authenticate
@ -179,38 +179,38 @@ commands::
# cat /sys/bus/thunderbolt/devices/0-0/nvm_version
18.0
If ``nvm_authenticate`` contains anything else than 0x0 it is the error
If ``nvm_authenticate`` contains anything other than 0x0 it is the error
code from the last authentication cycle, which means the authentication
of the NVM image failed.
Note names of the NVMem devices ``nvm_activeN`` and ``nvm_non_activeN``
depends on the order they are registered in the NVMem subsystem. N in
depend on the order they are registered in the NVMem subsystem. N in
the name is the identifier added by the NVMem subsystem.
Upgrading NVM when host controller is in safe mode
--------------------------------------------------
If the existing NVM is not properly authenticated (or is missing) the
host controller goes into safe mode which means that only available
functionality is flashing new NVM image. When in this mode the reading
host controller goes into safe mode which means that the only available
functionality is flashing a new NVM image. When in this mode, reading
``nvm_version`` fails with ``ENODATA`` and the device identification
information is missing.
To recover from this mode, one needs to flash a valid NVM image to the
host host controller in the same way it is done in the previous chapter.
host controller in the same way it is done in the previous chapter.
Networking over Thunderbolt cable
---------------------------------
Thunderbolt technology allows software communication across two hosts
Thunderbolt technology allows software communication between two hosts
connected by a Thunderbolt cable.
It is possible to tunnel any kind of traffic over Thunderbolt link but
It is possible to tunnel any kind of traffic over a Thunderbolt link but
currently we only support Apple ThunderboltIP protocol.
If the other host is running Windows or macOS only thing you need to
do is to connect Thunderbolt cable between the two hosts, the
``thunderbolt-net`` is loaded automatically. If the other host is also
Linux you should load ``thunderbolt-net`` manually on one host (it does
not matter which one)::
If the other host is running Windows or macOS, the only thing you need to
do is to connect a Thunderbolt cable between the two hosts; the
``thunderbolt-net`` driver is loaded automatically. If the other host is
also Linux you should load ``thunderbolt-net`` manually on one host (it
does not matter which one)::
# modprobe thunderbolt-net
@ -220,12 +220,12 @@ is built-in to the kernel image, there is no need to do anything.
The driver will create one virtual ethernet interface per Thunderbolt
port which are named like ``thunderbolt0`` and so on. From this point
you can either use standard userspace tools like ``ifconfig`` to
configure the interface or let your GUI to handle it automatically.
configure the interface or let your GUI handle it automatically.
Forcing power
-------------
Many OEMs include a method that can be used to force the power of a
thunderbolt controller to an "On" state even if nothing is connected.
Thunderbolt controller to an "On" state even if nothing is connected.
If supported by your machine this will be exposed by the WMI bus with
a sysfs attribute called "force_power".

31
Documentation/bpf/bpf_devel_QA.txt
View file

@ -516,4 +516,35 @@ A: LLVM has a -mcpu selector for the BPF back end in order to allow the
By the way, the BPF kernel selftests run with -mcpu=probe for better
test coverage.
Q: In some cases clang flag "-target bpf" is used but in other cases the
default clang target, which matches the underlying architecture, is used.
What is the difference and when I should use which?
A: Although LLVM IR generation and optimization try to stay architecture
independent, "-target <arch>" still has some impact on generated code:
- BPF program may recursively include header file(s) with file scope
inline assembly codes. The default target can handle this well,
while bpf target may fail if bpf backend assembler does not
understand these assembly codes, which is true in most cases.
- When compiled without -g, additional elf sections, e.g.,
.eh_frame and .rela.eh_frame, may be present in the object file
with default target, but not with bpf target.
- The default target may turn a C switch statement into a switch table
lookup and jump operation. Since the switch table is placed
in the global readonly section, the bpf program will fail to load.
The bpf target does not support switch table optimization.
The clang option "-fno-jump-tables" can be used to disable
switch table generation.
You should use default target when:
- Your program includes a header file, e.g., ptrace.h, which eventually
pulls in some header files containing file scope host assembly codes.
- You can add "-fno-jump-tables" to work around the switch table issue.
Otherwise, you can use bpf target.
Happy BPF hacking!

6
Documentation/devicetree/bindings/media/cec-gpio.txt
View file

@ -4,6 +4,10 @@ The HDMI CEC GPIO module supports CEC implementations where the CEC line
is hooked up to a pull-up GPIO line and - optionally - the HPD line is
hooked up to another GPIO line.
Please note: the maximum voltage for the CEC line is 3.63V, for the HPD
line it is 5.3V. So you may need some sort of level conversion circuitry
when connecting them to a GPIO line.
Required properties:
- compatible: value must be "cec-gpio".
- cec-gpios: gpio that the CEC line is connected to. The line should be
@ -21,7 +25,7 @@ the following property is optional:
Example for the Raspberry Pi 3 where the CEC line is connected to
pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
connected to pin 11 aka BCM17:
connected to pin 11 aka BCM17 (some level shifter is needed for this!):
#include <dt-bindings/gpio/gpio.h>

4
Documentation/devicetree/bindings/media/i2c/mt9m111.txt
View file

@ -6,6 +6,8 @@ interface.
Required Properties:
- compatible: value should be "micron,mt9m111"
- clocks: reference to the master clock.
- clock-names: shall be "mclk".
For further reading on port node refer to
Documentation/devicetree/bindings/media/video-interfaces.txt.
@ -16,6 +18,8 @@ Example:
mt9m111@5d {
compatible = "micron,mt9m111";
reg = <0x5d>;
clocks = <&mclk>;
clock-names = "mclk";
remote = <&pxa_camera>;
port {

46
Documentation/devicetree/bindings/media/i2c/ov5640.txt
View file

@ -1,4 +1,4 @@
* Omnivision OV5640 MIPI CSI-2 sensor
* Omnivision OV5640 MIPI CSI-2 / parallel sensor
Required Properties:
- compatible: should be "ovti,ov5640"
@ -18,7 +18,25 @@ The device node must contain one 'port' child node for its digital output
video port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Example:
OV5640 can be connected to a MIPI CSI-2 bus or a parallel bus endpoint.
Endpoint node required properties for CSI-2 connection are:
- remote-endpoint: a phandle to the bus receiver's endpoint node.
- clock-lanes: should be set to <0> (clock lane on hardware lane 0)
- data-lanes: should be set to <1> or <1 2> (one or two CSI-2 lanes supported)
Endpoint node required properties for parallel connection are:
- remote-endpoint: a phandle to the bus receiver's endpoint node.
- bus-width: shall be set to <8> for 8 bits parallel bus
or <10> for 10 bits parallel bus
- data-shift: shall be set to <2> for 8 bits parallel bus
(lines 9:2 are used) or <0> for 10 bits parallel bus
- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
signal.
Examples:
&i2c1 {
ov5640: camera@3c {
@ -35,6 +53,7 @@ Example:
reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
port {
/* MIPI CSI-2 bus endpoint */
ov5640_to_mipi_csi2: endpoint {
remote-endpoint = <&mipi_csi2_from_ov5640>;
clock-lanes = <0>;
@ -43,3 +62,26 @@ Example:
};
};
};
&i2c1 {
ov5640: camera@3c {
compatible = "ovti,ov5640";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ov5640>;
reg = <0x3c>;
clocks = <&clk_ext_camera>;
clock-names = "xclk";
port {
/* Parallel bus endpoint */
ov5640_to_parallel: endpoint {
remote-endpoint = <&parallel_from_ov5640>;
bus-width = <8>;
data-shift = <2>; /* lines 9:2 are used */
hsync-active = <0>;
vsync-active = <0>;
pclk-sample = <1>;
};
};
};
};

47
Documentation/devicetree/bindings/media/i2c/ov7740.txt Normal file
View file

@ -0,0 +1,47 @@
* Omnivision OV7740 CMOS image sensor
The Omnivision OV7740 image sensor supports multiple output image
size, such as VGA, and QVGA, CIF and any size smaller. It also
supports the RAW RGB and YUV output formats.
The common video interfaces bindings (see video-interfaces.txt) should
be used to specify link to the image data receiver. The OV7740 device
node should contain one 'port' child node with an 'endpoint' subnode.
Required Properties:
- compatible: "ovti,ov7740".
- reg: I2C slave address of the sensor.
- clocks: Reference to the xvclk input clock.
- clock-names: "xvclk".
Optional Properties:
- reset-gpios: Rreference to the GPIO connected to the reset_b pin,
if any. Active low with pull-ip resistor.
- powerdown-gpios: Reference to the GPIO connected to the pwdn pin,
if any. Active high with pull-down resistor.
Endpoint node mandatory properties:
- remote-endpoint: A phandle to the bus receiver's endpoint node.
Example:
i2c1: i2c@fc028000 {
ov7740: camera@21 {
compatible = "ovti,ov7740";
reg = <0x21>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sensor_power &pinctrl_sensor_reset>;
clocks = <&isc>;
clock-names = "xvclk";
assigned-clocks = <&isc>;
assigned-clock-rates = <24000000>;
reset-gpios = <&pioA 43 GPIO_ACTIVE_LOW>;
powerdown-gpios = <&pioA 44 GPIO_ACTIVE_HIGH>;
port {
ov7740_0: endpoint {
remote-endpoint = <&isc_0>;
};
};
};
};

7
Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
View file

@ -20,6 +20,13 @@ Mandatory properties
is in hardware standby mode when the signal is in the low state.
Optional properties
-------------------
- flash-leds: See ../video-interfaces.txt
- lens-focus: See ../video-interfaces.txt
Endpoint node mandatory properties
----------------------------------

55
Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt Normal file
View file

@ -0,0 +1,55 @@
NVIDIA Tegra Video Decoder Engine
Required properties:
- compatible : Must contain one of the following values:
- "nvidia,tegra20-vde"
- "nvidia,tegra30-vde"
- "nvidia,tegra114-vde"
- "nvidia,tegra124-vde"
- "nvidia,tegra132-vde"
- reg : Must contain an entry for each entry in reg-names.
- reg-names : Must include the following entries:
- sxe
- bsev
- mbe
- ppe
- mce
- tfe
- ppb
- vdma
- frameid
- iram : Must contain phandle to the mmio-sram device node that represents
IRAM region used by VDE.
- interrupts : Must contain an entry for each entry in interrupt-names.
- interrupt-names : Must include the following entries:
- sync-token
- bsev
- sxe
- clocks : Must include the following entries:
- vde
- resets : Must include the following entries:
- vde
Example:
video-codec@6001a000 {
compatible = "nvidia,tegra20-vde";
reg = <0x6001a000 0x1000 /* Syntax Engine */
0x6001b000 0x1000 /* Video Bitstream Engine */
0x6001c000 0x100 /* Macroblock Engine */
0x6001c200 0x100 /* Post-processing Engine */
0x6001c400 0x100 /* Motion Compensation Engine */
0x6001c600 0x100 /* Transform Engine */
0x6001c800 0x100 /* Pixel prediction block */
0x6001ca00 0x100 /* Video DMA */
0x6001d800 0x300 /* Video frame controls */>;
reg-names = "sxe", "bsev", "mbe", "ppe", "mce",
"tfe", "ppb", "vdma", "frameid";
iram = <&vde_pool>; /* IRAM region */
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, /* Sync token interrupt */
<GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, /* BSE-V interrupt */
<GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>; /* SXE interrupt */
interrupt-names = "sync-token", "bsev", "sxe";
clocks = <&tegra_car TEGRA20_CLK_VDE>;
resets = <&tegra_car 61>;
};

2
Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt
View file

@ -66,6 +66,6 @@ Example:
tpg1_out: endpoint {
remote-endpoint = <&switch_in0>;
};
}:
};
};
};

5
Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
View file

@ -4,7 +4,10 @@ This PCIe host controller is based on the Synopsys DesignWare PCIe IP
and thus inherits all the common properties defined in designware-pcie.txt.
Required properties:
- compatible: "axis,artpec6-pcie", "snps,dw-pcie"
- compatible: "axis,artpec6-pcie", "snps,dw-pcie" for ARTPEC-6 in RC mode;
"axis,artpec6-pcie-ep", "snps,dw-pcie" for ARTPEC-6 in EP mode;
"axis,artpec7-pcie", "snps,dw-pcie" for ARTPEC-7 in RC mode;
"axis,artpec7-pcie-ep", "snps,dw-pcie" for ARTPEC-7 in EP mode;
- reg: base addresses and lengths of the PCIe controller (DBI),
the PHY controller, and configuration address space.
- reg-names: Must include the following entries:

22
Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt Normal file
View file

@ -0,0 +1,22 @@
* Cadence PCIe endpoint controller
Required properties:
- compatible: Should contain "cdns,cdns-pcie-ep" to identify the IP used.
- reg: Should contain the controller register base address and AXI interface
region base address respectively.
- reg-names: Must be "reg" and "mem" respectively.
- cdns,max-outbound-regions: Set to maximum number of outbound regions
Optional properties:
- max-functions: Maximum number of functions that can be configured (default 1).
Example:
pcie@fc000000 {
compatible = "cdns,cdns-pcie-ep";
reg = <0x0 0xfc000000 0x0 0x01000000>,
<0x0 0x80000000 0x0 0x40000000>;
reg-names = "reg", "mem";
cdns,max-outbound-regions = <16>;
max-functions = /bits/ 8 <8>;
};

60
Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt Normal file
View file

@ -0,0 +1,60 @@
* Cadence PCIe host controller
This PCIe controller inherits the base properties defined in
host-generic-pci.txt.
Required properties:
- compatible: Should contain "cdns,cdns-pcie-host" to identify the IP used.
- reg: Should contain the controller register base address, PCIe configuration
window base address, and AXI interface region base address respectively.
- reg-names: Must be "reg", "cfg" and "mem" respectively.
- #address-cells: Set to <3>
- #size-cells: Set to <2>
- device_type: Set to "pci"
- ranges: Ranges for the PCI memory and I/O regions
- #interrupt-cells: Set to <1>
- interrupt-map-mask and interrupt-map: Standard PCI properties to define the
mapping of the PCIe interface to interrupt numbers.
Optional properties:
- cdns,max-outbound-regions: Set to maximum number of outbound regions
(default 32)
- cdns,no-bar-match-nbits: Set into the no BAR match register to configure the
number of least significant bits kept during inbound (PCIe -> AXI) address
translations (default 32)
- vendor-id: The PCI vendor ID (16 bits, default is design dependent)
- device-id: The PCI device ID (16 bits, default is design dependent)
Example:
pcie@fb000000 {
compatible = "cdns,cdns-pcie-host";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x0 0xff>;
linux,pci-domain = <0>;
cdns,max-outbound-regions = <16>;
cdns,no-bar-match-nbits = <32>;
vendor-id = /bits/ 16 <0x17cd>;
device-id = /bits/ 16 <0x0200>;
reg = <0x0 0xfb000000 0x0 0x01000000>,
<0x0 0x41000000 0x0 0x00001000>,
<0x0 0x40000000 0x0 0x04000000>;
reg-names = "reg", "cfg", "mem";
ranges = <0x02000000 0x0 0x42000000 0x0 0x42000000 0x0 0x1000000>,
<0x01000000 0x0 0x43000000 0x0 0x43000000 0x0 0x0010000>;
#interrupt-cells = <0x1>;
interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0x0 0x0 14 0x1
0x0 0x0 0x0 0x2 &gic 0x0 0x0 0x0 15 0x1
0x0 0x0 0x0 0x3 &gic 0x0 0x0 0x0 16 0x1
0x0 0x0 0x0 0x4 &gic 0x0 0x0 0x0 17 0x1>;
interrupt-map-mask = <0x0 0x0 0x0 0x7>;
msi-parent = <&its_pci>;
};

58
Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
View file

@ -6,9 +6,6 @@ and thus inherits all the common properties defined in designware-pcie.txt.
Required properties:
- compatible: "samsung,exynos5440-pcie"
- reg: base addresses and lengths of the PCIe controller,
the PHY controller, additional register for the PHY controller.
(Registers for the PHY controller are DEPRECATED.
Use the PHY framework.)
- reg-names : First name should be set to "elbi".
And use the "config" instead of getting the configuration address space
from "ranges".
@ -23,49 +20,8 @@ For other common properties, refer to
Example:
SoC-specific DT Entry:
SoC-specific DT Entry (with using PHY framework):
pcie@290000 {
compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
reg = <0x290000 0x1000
0x270000 0x1000
0x271000 0x40>;
interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
clocks = <&clock 28>, <&clock 27>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */
0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
num-lanes = <4>;
};
pcie@2a0000 {
compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
reg = <0x2a0000 0x1000
0x272000 0x1000
0x271040 0x40>;
interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
clocks = <&clock 29>, <&clock 27>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */
0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
num-lanes = <4>;
};
With using PHY framework:
pcie_phy0: pcie-phy@270000 {
...
reg = <0x270000 0x1000>, <0x271000 0x40>;
@ -74,13 +30,21 @@ With using PHY framework:
};
pcie@290000 {
...
compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
reg = <0x290000 0x1000>, <0x40000000 0x1000>;
reg-names = "elbi", "config";
clocks = <&clock 28>, <&clock 27>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
phys = <&pcie_phy0>;
ranges = <0x81000000 0 0 0x60001000 0 0x00010000
0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>;
...
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
num-lanes = <4>;
};
Board-specific DT Entry:

2
Documentation/devicetree/bindings/pwm/pwm-meson.txt
View file

@ -5,6 +5,8 @@ Required properties:
- compatible: Shall contain "amlogic,meson8b-pwm"
or "amlogic,meson-gxbb-pwm"
or "amlogic,meson-gxbb-ao-pwm"
or "amlogic,meson-axg-ee-pwm"
or "amlogic,meson-axg-ao-pwm"
- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
the cells format.

37
Documentation/devicetree/bindings/thermal/armada-thermal.txt
View file

@ -2,22 +2,35 @@
Required properties:
- compatible: Should be set to one of the following:
marvell,armada370-thermal
marvell,armada375-thermal
marvell,armada380-thermal
marvell,armadaxp-thermal
- compatible: Should be set to one of the following:
* marvell,armada370-thermal
* marvell,armada375-thermal
* marvell,armada380-thermal
* marvell,armadaxp-thermal
* marvell,armada-ap806-thermal
* marvell,armada-cp110-thermal
- reg: Device's register space.
Two entries are expected, see the examples below.
The first one is required for the sensor register;
the second one is required for the control register
to be used for sensor initialization (a.k.a. calibration).
- reg: Device's register space.
Two entries are expected, see the examples below. The first one points
to the status register (4B). The second one points to the control
registers (8B).
Note: The compatibles marvell,armada370-thermal,
marvell,armada380-thermal, and marvell,armadaxp-thermal must point to
"control MSB/control 1", with size of 4 (deprecated binding), or point
to "control LSB/control 0" with size of 8 (current binding). All other
compatibles must point to "control LSB/control 0" with size of 8.
Example:
Examples:
/* Legacy bindings */
thermal@d0018300 {
compatible = "marvell,armada370-thermal";
reg = <0xd0018300 0x4
reg = <0xd0018300 0x4
0xd0018304 0x4>;
};
ap_thermal: thermal@6f8084 {
compatible = "marvell,armada-ap806-thermal";
reg = <0x6f808C 0x4>,
<0x6f8084 0x8>;
};

1
Documentation/devicetree/bindings/thermal/rcar-thermal.txt
View file

@ -6,6 +6,7 @@ Required properties:
"renesas,rcar-thermal" (without thermal-zone) as fallback.
Examples with soctypes are:
- "renesas,thermal-r8a73a4" (R-Mobile APE6)
- "renesas,thermal-r8a7743" (RZ/G1M)
- "renesas,thermal-r8a7779" (R-Car H1)
- "renesas,thermal-r8a7790" (R-Car H2)
- "renesas,thermal-r8a7791" (R-Car M2-W)

1
Documentation/devicetree/bindings/vendor-prefixes.txt
View file

@ -125,6 +125,7 @@ focaltech FocalTech Systems Co.,Ltd
friendlyarm Guangzhou FriendlyARM Computer Tech Co., Ltd
fsl Freescale Semiconductor
fujitsu Fujitsu Ltd.
gcw Game Consoles Worldwide
ge General Electric Company
geekbuying GeekBuying
gef GE Fanuc Intelligent Platforms Embedded Systems, Inc.

17
Documentation/devicetree/bindings/watchdog/cortina,gemini-watchdog.txt
View file

@ -1,17 +0,0 @@
Cortina Systems Gemini SoC Watchdog
Required properties:
- compatible : must be "cortina,gemini-watchdog"
- reg : shall contain base register location and length
- interrupts : shall contain the interrupt for the watchdog
Optional properties:
- timeout-sec : the default watchdog timeout in seconds.
Example:
watchdog@41000000 {
compatible = "cortina,gemini-watchdog";
reg = <0x41000000 0x1000>;
interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
};

11
Documentation/devicetree/bindings/watchdog/cortina,gemin-watchdog.txt → Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.txt
View file

@ -1,7 +1,12 @@
Cortina Systems Gemini SoC Watchdog
Faraday Technology FTWDT010 watchdog
This is an IP part from Faraday Technology found in the Gemini
SoCs and others.
Required properties:
- compatible : must be "cortina,gemini-watchdog"
- compatible : must be one of
"faraday,ftwdt010"
"cortina,gemini-watchdog", "faraday,ftwdt010"
- reg : shall contain base register location and length
- interrupts : shall contain the interrupt for the watchdog
@ -11,7 +16,7 @@ Optional properties:
Example:
watchdog@41000000 {
compatible = "cortina,gemini-watchdog";
compatible = "faraday,ftwdt010";
reg = <0x41000000 0x1000>;
interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
};

4
Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt
View file

@ -1,7 +1,7 @@
Ingenic Watchdog Timer (WDT) Controller for JZ4740
Ingenic Watchdog Timer (WDT) Controller for JZ4740 & JZ4780
Required properties:
compatible: "ingenic,jz4740-watchdog"
compatible: "ingenic,jz4740-watchdog" or "ingenic,jz4780-watchdog"
reg: Register address and length for watchdog registers
Example:

17
Documentation/devicetree/bindings/watchdog/realtek,rtd119x.txt Normal file
View file

@ -0,0 +1,17 @@
Realtek RTD1295 Watchdog
========================
Required properties:
- compatible : Should be "realtek,rtd1295-watchdog"
- reg : Specifies the physical base address and size of registers
- clocks : Specifies one clock input
Example:
watchdog@98007680 {
compatible = "realtek,rtd1295-watchdog";
reg = <0x98007680 0x100>;
clocks = <&osc27M>;
};

3
Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
View file

@ -4,10 +4,11 @@ Required properties:
- compatible : Should be "renesas,<soctype>-wdt", and
"renesas,rcar-gen3-wdt" or "renesas,rza-wdt" as fallback.
Examples with soctypes are:
- "renesas,r7s72100-wdt" (RZ/A1)
- "renesas,r8a7795-wdt" (R-Car H3)
- "renesas,r8a7796-wdt" (R-Car M3-W)
- "renesas,r8a77970-wdt" (R-Car V3M)
- "renesas,r8a77995-wdt" (R-Car D3)
- "renesas,r7s72100-wdt" (RZ/A1)
When compatible with the generic version, nodes must list the SoC-specific
version corresponding to the platform first, followed by the generic

19
Documentation/devicetree/bindings/watchdog/sprd-wdt.txt Normal file
View file

@ -0,0 +1,19 @@
Spreadtrum SoCs Watchdog timer
Required properties:
- compatible : Should be "sprd,sp9860-wdt".
- reg : Specifies base physical address and size of the registers.
- interrupts : Exactly one interrupt specifier.
- timeout-sec : Contain the default watchdog timeout in seconds.
- clock-names : Contain the input clock names.
- clocks : Phandles to input clocks.
Example:
watchdog: watchdog@40310000 {
compatible = "sprd,sp9860-wdt";
reg = <0 0x40310000 0 0x1000>;
interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
timeout-sec = <12>;
clock-names = "enable", "rtc_enable";
clocks = <&clk_aon_apb_gates1 8>, <&clk_aon_apb_rtc_gates 9>;
};

106
Documentation/filesystems/overlayfs.txt
View file

@ -190,6 +190,20 @@ Mount options:
Redirects are not created and not followed (equivalent to "redirect_dir=off"
if "redirect_always_follow" feature is not enabled).
When the NFS export feature is enabled, every copied up directory is
indexed by the file handle of the lower inode and a file handle of the
upper directory is stored in a "trusted.overlay.upper" extended attribute
on the index entry. On lookup of a merged directory, if the upper
directory does not match the file handle stores in the index, that is an
indication that multiple upper directories may be redirected to the same
lower directory. In that case, lookup returns an error and warns about
a possible inconsistency.
Because lower layer redirects cannot be verified with the index, enabling
NFS export support on an overlay filesystem with no upper layer requires
turning off redirect follow (e.g. "redirect_dir=nofollow").
Non-directories
---------------
@ -281,9 +295,9 @@ filesystem, so both st_dev and st_ino of the file may change.
Any open files referring to this inode will access the old data.
If a file with multiple hard links is copied up, then this will
"break" the link. Changes will not be propagated to other names
referring to the same inode.
Unless "inode index" feature is enabled, if a file with multiple hard
links is copied up, then this will "break" the link. Changes will not be
propagated to other names referring to the same inode.
Unless "redirect_dir" feature is enabled, rename(2) on a lower or merged
directory will fail with EXDEV.
@ -299,6 +313,92 @@ filesystem are not allowed. If the underlying filesystem is changed,
the behavior of the overlay is undefined, though it will not result in
a crash or deadlock.
When the overlay NFS export feature is enabled, overlay filesystems
behavior on offline changes of the underlying lower layer is different
than the behavior when NFS export is disabled.
On every copy_up, an NFS file handle of the lower inode, along with the
UUID of the lower filesystem, are encoded and stored in an extended
attribute "trusted.overlay.origin" on the upper inode.
When the NFS export feature is enabled, a lookup of a merged directory,
that found a lower directory at the lookup path or at the path pointed
to by the "trusted.overlay.redirect" extended attribute, will verify
that the found lower directory file handle and lower filesystem UUID
match the origin file handle that was stored at copy_up time. If a
found lower directory does not match the stored origin, that directory
will not be merged with the upper directory.
NFS export
----------
When the underlying filesystems supports NFS export and the "nfs_export"
feature is enabled, an overlay filesystem may be exported to NFS.
With the "nfs_export" feature, on copy_up of any lower object, an index
entry is created under the index directory. The index entry name is the
hexadecimal representation of the copy up origin file handle. For a
non-directory object, the index entry is a hard link to the upper inode.
For a directory object, the index entry has an extended attribute
"trusted.overlay.upper" with an encoded file handle of the upper
directory inode.
When encoding a file handle from an overlay filesystem object, the
following rules apply:
1. For a non-upper object, encode a lower file handle from lower inode
2. For an indexed object, encode a lower file handle from copy_up origin
3. For a pure-upper object and for an existing non-indexed upper object,
encode an upper file handle from upper inode
The encoded overlay file handle includes:
- Header including path type information (e.g. lower/upper)
- UUID of the underlying filesystem
- Underlying filesystem encoding of underlying inode
This encoding format is identical to the encoding format file handles that
are stored in extended attribute "trusted.overlay.origin".
When decoding an overlay file handle, the following steps are followed:
1. Find underlying layer by UUID and path type information.
2. Decode the underlying filesystem file handle to underlying dentry.
3. For a lower file handle, lookup the handle in index directory by name.
4. If a whiteout is found in index, return ESTALE. This represents an
overlay object that was deleted after its file handle was encoded.
5. For a non-directory, instantiate a disconnected overlay dentry from the
decoded underlying dentry, the path type and index inode, if found.
6. For a directory, use the connected underlying decoded dentry, path type
and index, to lookup a connected overlay dentry.
Decoding a non-directory file handle may return a disconnected dentry.
copy_up of that disconnected dentry will create an upper index entry with
no upper alias.
When overlay filesystem has multiple lower layers, a middle layer
directory may have a "redirect" to lower directory. Because middle layer
"redirects" are not indexed, a lower file handle that was encoded from the
"redirect" origin directory, cannot be used to find the middle or upper
layer directory. Similarly, a lower file handle that was encoded from a
descendant of the "redirect" origin directory, cannot be used to
reconstruct a connected overlay path. To mitigate the cases of
directories that cannot be decoded from a lower file handle, these
directories are copied up on encode and encoded as an upper file handle.
On an overlay filesystem with no upper layer this mitigation cannot be
used NFS export in this setup requires turning off redirect follow (e.g.
"redirect_dir=nofollow").
The overlay filesystem does not support non-directory connectable file
handles, so exporting with the 'subtree_check' exportfs configuration will
cause failures to lookup files over NFS.
When the NFS export feature is enabled, all directory index entries are
verified on mount time to check that upper file handles are not stale.
This verification may cause significant overhead in some cases.
Testsuite
---------

2
Documentation/infiniband/user_verbs.txt
View file

@ -5,7 +5,7 @@ USERSPACE VERBS ACCESS
described in chapter 11 of the InfiniBand Architecture Specification.
To use the verbs, the libibverbs library, available from
http://www.openfabrics.org/, is required. libibverbs contains a
https://github.com/linux-rdma/rdma-core, is required. libibverbs contains a
device-independent API for using the ib_uverbs interface.
libibverbs also requires appropriate device-dependent kernel and
userspace driver for your InfiniBand hardware. For example, to use

2
Documentation/media/dmx.h.rst.exceptions
View file

@ -54,3 +54,5 @@ ignore symbol DMX_OUT_DECODER
ignore symbol DMX_OUT_TAP
ignore symbol DMX_OUT_TS_TAP
ignore symbol DMX_OUT_TSDEMUX_TAP
replace ioctl DMX_DQBUF dmx_qbuf

14
Documentation/media/kapi/cec-core.rst
View file

@ -103,6 +103,7 @@ your driver:
/* Low-level callbacks */
int (*adap_enable)(struct cec_adapter *adap, bool enable);
int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable);
int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable);
int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
u32 signal_free_time, struct cec_msg *msg);
@ -144,6 +145,19 @@ called if the CEC_CAP_MONITOR_ALL capability is set. This callback is optional
Note that adap_monitor_all_enable must return 0 if enable is false.
To enable/disable the 'monitor pin' mode:
.. c:function::
int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable);
If enabled, then the adapter should be put in a mode to also monitor CEC pin
changes. Not all hardware supports this and this function is only called if
the CEC_CAP_MONITOR_PIN capability is set. This callback is optional
(some hardware may always be in 'monitor pin' mode).
Note that adap_monitor_pin_enable must return 0 if enable is false.
To program a new logical address:
.. c:function::

2
Documentation/media/kapi/dtv-ca.rst
View file

@ -1,4 +1,4 @@
Digital TV Conditional Access kABI
----------------------------------
.. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h
.. kernel-doc:: include/media/dvb_ca_en50221.h

11
Documentation/media/kapi/dtv-common.rst
View file

@ -7,7 +7,7 @@ Math functions
Provide some commonly-used math functions, usually required in order to
estimate signal strength and signal to noise measurements in dB.
.. kernel-doc:: drivers/media/dvb-core/dvb_math.h
.. kernel-doc:: include/media/dvb_math.h
DVB devices
@ -15,7 +15,7 @@ DVB devices
Those functions are responsible for handling the DVB device nodes.
.. kernel-doc:: drivers/media/dvb-core/dvbdev.h
.. kernel-doc:: include/media/dvbdev.h
Digital TV Ring buffer
~~~~~~~~~~~~~~~~~~~~~~
@ -52,4 +52,9 @@ copy it from/to userspace.
Resetting the buffer counts as a read and write operation.
Two or more writers must be locked against each other.
.. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h
.. kernel-doc:: include/media/dvb_ringbuffer.h
Digital TV VB2 handler
~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: include/media/dvb_vb2.h

8
Documentation/media/kapi/dtv-demux.rst
View file

@ -8,7 +8,7 @@ The Kernel Digital TV Demux kABI defines a driver-internal interface for
registering low-level, hardware specific driver to a hardware independent
demux layer. It is only of interest for Digital TV device driver writers.
The header file for this kABI is named ``demux.h`` and located in
``drivers/media/dvb-core``.
``include/media``.
The demux kABI should be implemented for each demux in the system. It is
used to select the TS source of a demux and to manage the demux resources.
@ -69,14 +69,14 @@ callbacks.
Digital TV Demux device registration functions and data structures
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/media/dvb-core/dmxdev.h
.. kernel-doc:: include/media/dmxdev.h
High-level Digital TV demux interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/media/dvb-core/dvb_demux.h
.. kernel-doc:: include/media/dvb_demux.h
Driver-internal low-level hardware specific driver demux interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/media/dvb-core/demux.h
.. kernel-doc:: include/media/demux.h

8
Documentation/media/kapi/dtv-frontend.rst
View file

@ -8,7 +8,7 @@ The Digital TV Frontend kABI defines a driver-internal interface for
registering low-level, hardware specific driver to a hardware independent
frontend layer. It is only of interest for Digital TV device driver writers.
The header file for this API is named ``dvb_frontend.h`` and located in
``drivers/media/dvb-core``.
``include/media/``.
Demodulator driver
^^^^^^^^^^^^^^^^^^
@ -17,7 +17,7 @@ The demodulator driver is responsible to talk with the decoding part of the
hardware. Such driver should implement :c:type:`dvb_frontend_ops`, with
tells what type of digital TV standards are supported, and points to a
series of functions that allow the DVB core to command the hardware via
the code under ``drivers/media/dvb-core/dvb_frontend.c``.
the code under ``include/media/dvb_frontend.c``.
A typical example of such struct in a driver ``foo`` is::
@ -118,7 +118,7 @@ Satellite TV reception is::
.. |delta| unicode:: U+00394
The ``drivers/media/dvb-core/dvb_frontend.c`` has a kernel thread with is
The ``include/media/dvb_frontend.c`` has a kernel thread with is
responsible for tuning the device. It supports multiple algorithms to
detect a channel, as defined at enum :c:func:`dvbfe_algo`.
@ -440,4 +440,4 @@ monotonic stats at the right time.
Digital TV Frontend functions and types
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/media/dvb-core/dvb_frontend.h
.. kernel-doc:: include/media/dvb_frontend.h

2
Documentation/media/kapi/dtv-net.rst
View file

@ -1,4 +1,4 @@
Digital TV Network kABI
-----------------------
.. kernel-doc:: drivers/media/dvb-core/dvb_net.h
.. kernel-doc:: include/media/dvb_net.h

82
Documentation/media/kapi/rc-core.rst
View file

@ -4,11 +4,83 @@ Remote Controller devices
Remote Controller core
~~~~~~~~~~~~~~~~~~~~~~
The remote controller core implements infrastructure to receive and send
remote controller keyboard keystrokes and mouse events.
Every time a key is pressed on a remote controller, a scan code is produced.
Also, on most hardware, keeping a key pressed for more than a few dozens of
milliseconds produce a repeat key event. That's somewhat similar to what
a normal keyboard or mouse is handled internally on Linux\ [#f1]_. So, the
remote controller core is implemented on the top of the linux input/evdev
interface.
.. [#f1]
The main difference is that, on keyboard events, the keyboard controller
produces one event for a key press and another one for key release. On
infrared-based remote controllers, there's no key release event. Instead,
an extra code is produced to indicate key repeats.
However, most of the remote controllers use infrared (IR) to transmit signals.
As there are several protocols used to modulate infrared signals, one
important part of the core is dedicated to adjust the driver and the core
system to support the infrared protocol used by the emitter.
The infrared transmission is done by blinking a infrared emitter using a
carrier. The carrier can be switched on or off by the IR transmitter
hardware. When the carrier is switched on, it is called *PULSE*.
When the carrier is switched off, it is called *SPACE*.
In other words, a typical IR transmission can be viewed as a sequence of
*PULSE* and *SPACE* events, each with a given duration.
The carrier parameters (frequency, duty cycle) and the intervals for
*PULSE* and *SPACE* events depend on the protocol.
For example, the NEC protocol uses a carrier of 38kHz, and transmissions
start with a 9ms *PULSE* and a 4.5ms SPACE. It then transmits 16 bits of
scan code, being 8 bits for address (usually it is a fixed number for a
given remote controller), followed by 8 bits of code. A bit "1" is modulated
with 560µs *PULSE* followed by 1690µs *SPACE* and a bit "0" is modulated
with 560µs *PULSE* followed by 560µs *SPACE*.
At receiver, a simple low-pass filter can be used to convert the received
signal in a sequence of *PULSE/SPACE* events, filtering out the carrier
frequency. Due to that, the receiver doesn't care about the carrier's
actual frequency parameters: all it has to do is to measure the amount
of time it receives *PULSE/SPACE* events.
So, a simple IR receiver hardware will just provide a sequence of timings
for those events to the Kernel. The drivers for hardware with such kind of
receivers are identified by ``RC_DRIVER_IR_RAW``, as defined by
:c:type:`rc_driver_type`\ [#f2]_. Other hardware come with a
microcontroller that decode the *PULSE/SPACE* sequence and return scan
codes to the Kernel. Such kind of receivers are identified
by ``RC_DRIVER_SCANCODE``.
.. [#f2]
The RC core also supports devices that have just IR emitters,
without any receivers. Right now, all such devices work only in
raw TX mode. Such kind of hardware is identified as
``RC_DRIVER_IR_RAW_TX``.
When the RC core receives events produced by ``RC_DRIVER_IR_RAW`` IR
receivers, it needs to decode the IR protocol, in order to obtain the
corresponding scan code. The protocols supported by the RC core are
defined at enum :c:type:`rc_proto`.
When the RC code receives a scan code (either directly, by a driver
of the type ``RC_DRIVER_SCANCODE``, or via its IR decoders), it needs
to convert into a Linux input event code. This is done via a mapping
table.
The Kernel has support for mapping tables available on most media
devices. It also supports loading a table in runtime, via some
sysfs nodes. See the :ref:`RC userspace API <Remote_controllers_Intro>`
for more details.
Remote controller data structures and functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/rc-core.h
.. kernel-doc:: include/media/rc-map.h
LIRC
~~~~
.. kernel-doc:: include/media/lirc_dev.h

17
Documentation/media/kapi/v4l2-dev.rst
View file

@ -196,11 +196,18 @@ device.
Which device is registered depends on the type argument. The following
types exist:
- ``VFL_TYPE_GRABBER``: ``/dev/videoX`` for video input/output devices
- ``VFL_TYPE_VBI``: ``/dev/vbiX`` for vertical blank data (i.e. closed captions, teletext)
- ``VFL_TYPE_RADIO``: ``/dev/radioX`` for radio tuners
- ``VFL_TYPE_SDR``: ``/dev/swradioX`` for Software Defined Radio tuners
- ``VFL_TYPE_TOUCH``: ``/dev/v4l-touchX`` for touch sensors
========================== ==================== ==============================
:c:type:`vfl_devnode_type` Device name Usage
========================== ==================== ==============================
``VFL_TYPE_GRABBER`` ``/dev/videoX`` for video input/output devices
``VFL_TYPE_VBI`` ``/dev/vbiX`` for vertical blank data (i.e.
closed captions, teletext)
``VFL_TYPE_RADIO`` ``/dev/radioX`` for radio tuners
``VFL_TYPE_SUBDEV`` ``/dev/v4l-subdevX`` for V4L2 subdevices
``VFL_TYPE_SDR`` ``/dev/swradioX`` for Software Defined Radio
(SDR) tuners
``VFL_TYPE_TOUCH`` ``/dev/v4l-touchX`` for touch sensors
========================== ==================== ==============================
The last argument gives you a certain amount of control over the device
device node number used (i.e. the X in ``videoX``). Normally you will pass -1

67
Documentation/media/kapi/v4l2-event.rst
View file

@ -5,27 +5,68 @@ V4L2 events
The V4L2 events provide a generic way to pass events to user space.
The driver must use :c:type:`v4l2_fh` to be able to support V4L2 events.
Events are defined by a type and an optional ID. The ID may refer to a V4L2
object such as a control ID. If unused, then the ID is 0.
Events are subscribed per-filehandle. An event specification consists of a
``type`` and is optionally associated with an object identified through the
``id`` field. If unused, then the ``id`` is 0. So an event is uniquely
identified by the ``(type, id)`` tuple.
When the user subscribes to an event the driver will allocate a number of
kevent structs for that event. So every (type, ID) event tuple will have
its own set of kevent structs. This guarantees that if a driver is generating
lots of events of one type in a short time, then that will not overwrite
events of another type.
The :c:type:`v4l2_fh` struct has a list of subscribed events on its
``subscribed`` field.
But if you get more events of one type than the number of kevents that were
reserved, then the oldest event will be dropped and the new one added.
When the user subscribes to an event, a :c:type:`v4l2_subscribed_event`
struct is added to :c:type:`v4l2_fh`\ ``.subscribed``, one for every
subscribed event.
Each :c:type:`v4l2_subscribed_event` struct ends with a
:c:type:`v4l2_kevent` ringbuffer, with the size given by the caller
of :c:func:`v4l2_event_subscribe`. This ringbuffer is used to store any events
raised by the driver.
So every ``(type, ID)`` event tuple will have its own
:c:type:`v4l2_kevent` ringbuffer. This guarantees that if a driver is
generating lots of events of one type in a short time, then that will
not overwrite events of another type.
But if you get more events of one type than the size of the
:c:type:`v4l2_kevent` ringbuffer, then the oldest event will be dropped
and the new one added.
The :c:type:`v4l2_kevent` struct links into the ``available``
list of the :c:type:`v4l2_fh` struct so :ref:`VIDIOC_DQEVENT` will
know which event to dequeue first.
Finally, if the event subscription is associated with a particular object
such as a V4L2 control, then that object needs to know about that as well
so that an event can be raised by that object. So the ``node`` field can
be used to link the :c:type:`v4l2_subscribed_event` struct into a list of
such objects.
So to summarize:
- struct :c:type:`v4l2_fh` has two lists: one of the ``subscribed`` events,
and one of the ``available`` events.
- struct :c:type:`v4l2_subscribed_event` has a ringbuffer of raised
(pending) events of that particular type.
- If struct :c:type:`v4l2_subscribed_event` is associated with a specific
object, then that object will have an internal list of
struct :c:type:`v4l2_subscribed_event` so it knows who subscribed an
event to that object.
Furthermore, the internal struct :c:type:`v4l2_subscribed_event` has
``merge()`` and ``replace()`` callbacks which drivers can set. These
callbacks are called when a new event is raised and there is no more room.
The ``replace()`` callback allows you to replace the payload of the old event
with that of the new event, merging any relevant data from the old payload
into the new payload that replaces it. It is called when this event type has
only one kevent struct allocated. The ``merge()`` callback allows you to merge
the oldest event payload into that of the second-oldest event payload. It is
called when there are two or more kevent structs allocated.
a ringbuffer with size is one, i.e. only one event can be stored in the
ringbuffer.
The ``merge()`` callback allows you to merge the oldest event payload into
that of the second-oldest event payload. It is called when
the ringbuffer has size is greater than one.
This way no status information is lost, just the intermediate steps leading
up to that state.
@ -73,7 +114,7 @@ The ops argument allows the driver to specify a number of callbacks:
Callback Description
======== ==============================================================
add called when a new listener gets added (subscribing to the same
event twice will only cause this callback to get called once)
event twice will only cause this callback to get called once)
del called when a listener stops listening
replace replace event 'old' with event 'new'.
merge merge event 'old' into event 'new'.

31
Documentation/media/lirc.h.rst.exceptions
View file

@ -28,6 +28,36 @@ ignore define LIRC_CAN_SEND_MASK
ignore define LIRC_CAN_REC_MASK
ignore define LIRC_CAN_SET_REC_DUTY_CYCLE
# Obsolete ioctls
ignore ioctl LIRC_GET_LENGTH
# rc protocols
ignore symbol RC_PROTO_UNKNOWN
ignore symbol RC_PROTO_OTHER
ignore symbol RC_PROTO_RC5
ignore symbol RC_PROTO_RC5X_20
ignore symbol RC_PROTO_RC5_SZ
ignore symbol RC_PROTO_JVC
ignore symbol RC_PROTO_SONY12
ignore symbol RC_PROTO_SONY15
ignore symbol RC_PROTO_SONY20
ignore symbol RC_PROTO_NEC
ignore symbol RC_PROTO_NECX
ignore symbol RC_PROTO_NEC32
ignore symbol RC_PROTO_SANYO
ignore symbol RC_PROTO_MCIR2_KBD
ignore symbol RC_PROTO_MCIR2_MSE
ignore symbol RC_PROTO_RC6_0
ignore symbol RC_PROTO_RC6_6A_20
ignore symbol RC_PROTO_RC6_6A_24
ignore symbol RC_PROTO_RC6_6A_32
ignore symbol RC_PROTO_RC6_MCE
ignore symbol RC_PROTO_SHARP
ignore symbol RC_PROTO_XMP
ignore symbol RC_PROTO_CEC
# Undocumented macros
ignore define PULSE_BIT
@ -40,3 +70,4 @@ ignore define LIRC_VALUE_MASK
ignore define LIRC_MODE2_MASK
ignore define LIRC_MODE_RAW
ignore define LIRC_MODE_LIRCCODE

88
Documentation/media/uapi/dvb/dmx-expbuf.rst Normal file
View file

@ -0,0 +1,88 @@
.. _DMX_EXPBUF:
****************
ioctl DMX_EXPBUF
****************
Name
====
DMX_EXPBUF - Export a buffer as a DMABUF file descriptor.
.. warning:: this API is still experimental
Synopsis
========
.. c:function:: int ioctl( int fd, DMX_EXPBUF, struct dmx_exportbuffer *argp )
:name: DMX_EXPBUF
Arguments
=========
``fd``
File descriptor returned by :ref:`open() <dmx_fopen>`.
``argp``
Pointer to struct :c:type:`dmx_exportbuffer`.
Description
===========
This ioctl is an extension to the memory mapping I/O method.
It can be used to export a buffer as a DMABUF file at any time after
buffers have been allocated with the :ref:`DMX_REQBUFS` ioctl.
To export a buffer, applications fill struct :c:type:`dmx_exportbuffer`.
Applications must set the ``index`` field. Valid index numbers
range from zero to the number of buffers allocated with :ref:`DMX_REQBUFS`
(struct :c:type:`dmx_requestbuffers` ``count``) minus one.
Additional flags may be posted in the ``flags`` field. Refer to a manual
for open() for details. Currently only O_CLOEXEC, O_RDONLY, O_WRONLY,
and O_RDWR are supported.
All other fields must be set to zero. In the
case of multi-planar API, every plane is exported separately using
multiple :ref:`DMX_EXPBUF` calls.
After calling :ref:`DMX_EXPBUF` the ``fd`` field will be set by a
driver, on success. This is a DMABUF file descriptor. The application may
pass it to other DMABUF-aware devices. It is recommended to close a DMABUF
file when it is no longer used to allow the associated memory to be reclaimed.
Examples
========
.. code-block:: c
int buffer_export(int v4lfd, enum dmx_buf_type bt, int index, int *dmafd)
{
struct dmx_exportbuffer expbuf;
memset(&expbuf, 0, sizeof(expbuf));
expbuf.type = bt;
expbuf.index = index;
if (ioctl(v4lfd, DMX_EXPBUF, &expbuf) == -1) {
perror("DMX_EXPBUF");
return -1;
}
*dmafd = expbuf.fd;
return 0;
}
Return Value
============
On success 0 is returned, on error -1 and the ``errno`` variable is set
appropriately. The generic error codes are described at the
:ref:`Generic Error Codes <gen-errors>` chapter.
EINVAL
A queue is not in MMAP mode or DMABUF exporting is not supported or
``flags`` or ``index`` fields are invalid.

116
Documentation/media/uapi/dvb/dmx-mmap.rst Normal file
View file

@ -0,0 +1,116 @@
.. _dmx-mmap:
*****************
Digital TV mmap()
*****************
Name
====
dmx-mmap - Map device memory into application address space
.. warning:: this API is still experimental
Synopsis
========
.. code-block:: c
#include <unistd.h>
#include <sys/mman.h>
.. c:function:: void *mmap( void *start, size_t length, int prot, int flags, int fd, off_t offset )
:name: dmx-mmap
Arguments
=========
``start``
Map the buffer to this address in the application's address space.
When the ``MAP_FIXED`` flag is specified, ``start`` must be a
multiple of the pagesize and mmap will fail when the specified
address cannot be used. Use of this option is discouraged;
applications should just specify a ``NULL`` pointer here.
``length``
Length of the memory area to map. This must be a multiple of the
DVB packet length (188, on most drivers).
``prot``
The ``prot`` argument describes the desired memory protection.
Regardless of the device type and the direction of data exchange it
should be set to ``PROT_READ`` | ``PROT_WRITE``, permitting read
and write access to image buffers. Drivers should support at least
this combination of flags.
``flags``
The ``flags`` parameter specifies the type of the mapped object,
mapping options and whether modifications made to the mapped copy of
the page are private to the process or are to be shared with other
references.
``MAP_FIXED`` requests that the driver selects no other address than
the one specified. If the specified address cannot be used,
:ref:`mmap() <dmx-mmap>` will fail. If ``MAP_FIXED`` is specified,
``start`` must be a multiple of the pagesize. Use of this option is
discouraged.
One of the ``MAP_SHARED`` or ``MAP_PRIVATE`` flags must be set.
``MAP_SHARED`` allows applications to share the mapped memory with
other (e. g. child-) processes.
.. note::
The Linux Digital TV applications should not set the
``MAP_PRIVATE``, ``MAP_DENYWRITE``, ``MAP_EXECUTABLE`` or ``MAP_ANON``
flags.
``fd``
File descriptor returned by :ref:`open() <dmx_fopen>`.
``offset``
Offset of the buffer in device memory, as returned by
:ref:`DMX_QUERYBUF` ioctl.
Description
===========
The :ref:`mmap() <dmx-mmap>` function asks to map ``length`` bytes starting at
``offset`` in the memory of the device specified by ``fd`` into the
application address space, preferably at address ``start``. This latter
address is a hint only, and is usually specified as 0.
Suitable length and offset parameters are queried with the
:ref:`DMX_QUERYBUF` ioctl. Buffers must be allocated with the
:ref:`DMX_REQBUFS` ioctl before they can be queried.
To unmap buffers the :ref:`munmap() <dmx-munmap>` function is used.
Return Value
============
On success :ref:`mmap() <dmx-mmap>` returns a pointer to the mapped buffer. On
error ``MAP_FAILED`` (-1) is returned, and the ``errno`` variable is set
appropriately. Possible error codes are:
EBADF
``fd`` is not a valid file descriptor.
EACCES
``fd`` is not open for reading and writing.
EINVAL
The ``start`` or ``length`` or ``offset`` are not suitable. (E. g.
they are too large, or not aligned on a ``PAGESIZE`` boundary.)
The ``flags`` or ``prot`` value is not supported.
No buffers have been allocated with the
:ref:`DMX_REQBUFS` ioctl.
ENOMEM
Not enough physical or virtual memory was available to complete the
request.

54
Documentation/media/uapi/dvb/dmx-munmap.rst Normal file
View file

@ -0,0 +1,54 @@
.. _dmx-munmap:
************
DVB munmap()
************
Name
====
dmx-munmap - Unmap device memory
.. warning:: This API is still experimental.
Synopsis
========
.. code-block:: c
#include <unistd.h>
#include <sys/mman.h>
.. c:function:: int munmap( void *start, size_t length )
:name: dmx-munmap
Arguments
=========
``start``
Address of the mapped buffer as returned by the
:ref:`mmap() <dmx-mmap>` function.
``length``
Length of the mapped buffer. This must be the same value as given to
:ref:`mmap() <dmx-mmap>`.
Description
===========
Unmaps a previously with the :ref:`mmap() <dmx-mmap>` function mapped
buffer and frees it, if possible.
Return Value
============
On success :ref:`munmap() <dmx-munmap>` returns 0, on failure -1 and the
``errno`` variable is set appropriately:
EINVAL
The ``start`` or ``length`` is incorrect, or no buffers have been
mapped yet.

83
Documentation/media/uapi/dvb/dmx-qbuf.rst Normal file
View file

@ -0,0 +1,83 @@
.. _DMX_QBUF:
*************************
ioctl DMX_QBUF, DMX_DQBUF
*************************
Name
====
DMX_QBUF - DMX_DQBUF - Exchange a buffer with the driver
.. warning:: this API is still experimental
Synopsis
========
.. c:function:: int ioctl( int fd, DMX_QBUF, struct dmx_buffer *argp )
:name: DMX_QBUF
.. c:function:: int ioctl( int fd, DMX_DQBUF, struct dmx_buffer *argp )
:name: DMX_DQBUF
Arguments
=========
``fd``
File descriptor returned by :ref:`open() <dmx_fopen>`.
``argp``
Pointer to struct :c:type:`dmx_buffer`.
Description
===========
Applications call the ``DMX_QBUF`` ioctl to enqueue an empty
(capturing) or filled (output) buffer in the driver's incoming queue.
The semantics depend on the selected I/O method.
To enqueue a buffer applications set the ``index`` field. Valid index
numbers range from zero to the number of buffers allocated with
:ref:`DMX_REQBUFS` (struct :c:type:`dmx_requestbuffers` ``count``) minus
one. The contents of the struct :c:type:`dmx_buffer` returned
by a :ref:`DMX_QUERYBUF` ioctl will do as well.
When ``DMX_QBUF`` is called with a pointer to this structure, it locks the
memory pages of the buffer in physical memory, so they cannot be swapped
out to disk. Buffers remain locked until dequeued, until the
the device is closed.
Applications call the ``DMX_DQBUF`` ioctl to dequeue a filled
(capturing) buffer from the driver's outgoing queue. They just set the ``reserved`` field array to zero. When ``DMX_DQBUF`` is called with a
pointer to this structure, the driver fills the remaining fields or
returns an error code.
By default ``DMX_DQBUF`` blocks when no buffer is in the outgoing
queue. When the ``O_NONBLOCK`` flag was given to the
:ref:`open() <dmx_fopen>` function, ``DMX_DQBUF`` returns
immediately with an ``EAGAIN`` error code when no buffer is available.
The struct :c:type:`dmx_buffer` structure is specified in
:ref:`buffer`.
Return Value
============
On success 0 is returned, on error -1 and the ``errno`` variable is set
appropriately. The generic error codes are described at the
:ref:`Generic Error Codes <gen-errors>` chapter.
EAGAIN
Non-blocking I/O has been selected using ``O_NONBLOCK`` and no
buffer was in the outgoing queue.
EINVAL
The ``index`` is out of bounds, or no buffers have been allocated yet.
EIO
``DMX_DQBUF`` failed due to an internal error. Can also indicate
temporary problems like signal loss or CRC errors.

63
Documentation/media/uapi/dvb/dmx-querybuf.rst Normal file
View file

@ -0,0 +1,63 @@
.. _DMX_QUERYBUF:
******************
ioctl DMX_QUERYBUF
******************
Name
====
DMX_QUERYBUF - Query the status of a buffer
.. warning:: this API is still experimental
Synopsis
========
.. c:function:: int ioctl( int fd, DMX_QUERYBUF, struct dvb_buffer *argp )
:name: DMX_QUERYBUF
Arguments
=========
``fd``
File descriptor returned by :ref:`open() <dmx_fopen>`.
``argp``
Pointer to struct :c:type:`dvb_buffer`.
Description
===========
This ioctl is part of the mmap streaming I/O method. It can
be used to query the status of a buffer at any time after buffers have
been allocated with the :ref:`DMX_REQBUFS` ioctl.
Applications set the ``index`` field. Valid index numbers range from zero
to the number of buffers allocated with :ref:`DMX_REQBUFS`
(struct :c:type:`dvb_requestbuffers` ``count``) minus one.
After calling :ref:`DMX_QUERYBUF` with a pointer to this structure,
drivers return an error code or fill the rest of the structure.
On success, the ``offset`` will contain the offset of the buffer from the
start of the device memory, the ``length`` field its size, and the
``bytesused`` the number of bytes occupied by data in the buffer (payload).
Return Value
============
On success 0 is returned, the ``offset`` will contain the offset of the
buffer from the start of the device memory, the ``length`` field its size,
and the ``bytesused`` the number of bytes occupied by data in the buffer
(payload).
On error it returns -1 and the ``errno`` variable is set
appropriately. The generic error codes are described at the
:ref:`Generic Error Codes <gen-errors>` chapter.
EINVAL
The ``index`` is out of bounds.

74
Documentation/media/uapi/dvb/dmx-reqbufs.rst Normal file
View file

@ -0,0 +1,74 @@
.. _DMX_REQBUFS:
*****************
ioctl DMX_REQBUFS
*****************
Name
====
DMX_REQBUFS - Initiate Memory Mapping and/or DMA buffer I/O
.. warning:: this API is still experimental
Synopsis
========
.. c:function:: int ioctl( int fd, DMX_REQBUFS, struct dmx_requestbuffers *argp )
:name: DMX_REQBUFS
Arguments
=========
``fd``
File descriptor returned by :ref:`open() <dmx_fopen>`.
``argp``
Pointer to struct :c:type:`dmx_requestbuffers`.
Description
===========
This ioctl is used to initiate a memory mapped or DMABUF based demux I/O.
Memory mapped buffers are located in device memory and must be allocated
with this ioctl before they can be mapped into the application's address
space. User buffers are allocated by applications themselves, and this
ioctl is merely used to switch the driver into user pointer I/O mode and
to setup some internal structures. Similarly, DMABUF buffers are
allocated by applications through a device driver, and this ioctl only
configures the driver into DMABUF I/O mode without performing any direct
allocation.
To allocate device buffers applications initialize all fields of the
struct :c:type:`dmx_requestbuffers` structure. They set the ``count`` field
to the desired number of buffers, and ``size`` to the size of each
buffer.
When the ioctl is called with a pointer to this structure, the driver will
attempt to allocate the requested number of buffers and it stores the actual
number allocated in the ``count`` field. The ``count`` can be smaller than the number requested, even zero, when the driver runs out of free memory. A larger
number is also possible when the driver requires more buffers to
function correctly. The actual allocated buffer size can is returned
at ``size``, and can be smaller than what's requested.
When this I/O method is not supported, the ioctl returns an ``EOPNOTSUPP``
error code.
Applications can call :ref:`DMX_REQBUFS` again to change the number of
buffers, however this cannot succeed when any buffers are still mapped.
A ``count`` value of zero frees all buffers, after aborting or finishing
any DMA in progress.
Return Value
============
On success 0 is returned, on error -1 and the ``errno`` variable is set
appropriately. The generic error codes are described at the
:ref:`Generic Error Codes <gen-errors>` chapter.
EOPNOTSUPP
The the requested I/O method is not supported.

6
Documentation/media/uapi/dvb/dmx_fcalls.rst
View file

@ -13,6 +13,8 @@ Demux Function Calls
dmx-fclose
dmx-fread
dmx-fwrite
dmx-mmap
dmx-munmap
dmx-start
dmx-stop
dmx-set-filter
@ -22,3 +24,7 @@ Demux Function Calls
dmx-get-pes-pids
dmx-add-pid
dmx-remove-pid
dmx-reqbufs
dmx-querybuf
dmx-expbuf
dmx-qbuf

18
Documentation/media/uapi/dvb/fe_property_parameters.rst
View file

@ -987,3 +987,21 @@ Possible values: 0, 1, LNA_AUTO
1, LNA on
use the special macro LNA_AUTO to set LNA auto
.. _DTV-SCRAMBLING-SEQUENCE-INDEX:
DTV_SCRAMBLING_SEQUENCE_INDEX
=============================
Used on DVB-S2.
This 18 bit field, when present, carries the index of the DVB-S2 physical
layer scrambling sequence as defined in clause 5.5.4 of EN 302 307.
There is no explicit signalling method to convey scrambling sequence index
to the receiver. If S2 satellite delivery system descriptor is available
it can be used to read the scrambling sequence index (EN 300 468 table 41).
By default, gold scrambling sequence index 0 is used.
The valid scrambling sequence index range is from 0 to 262142.

2
Documentation/media/uapi/dvb/frontend-property-satellite-systems.rst
View file

@ -60,6 +60,8 @@ following parameters:
- :ref:`DTV_STREAM_ID <DTV-STREAM-ID>`
- :ref:`DTV_SCRAMBLING_SEQUENCE_INDEX <DTV-SCRAMBLING-SEQUENCE-INDEX>`
In addition, the :ref:`DTV QoS statistics <frontend-stat-properties>`
are also valid.

75
Documentation/media/uapi/rc/lirc-dev-intro.rst
View file

@ -6,11 +6,12 @@
Introduction
************
The LIRC device interface is a bi-directional interface for transporting
raw IR data between userspace and kernelspace. Fundamentally, it is just
a chardev (/dev/lircX, for X = 0, 1, 2, ...), with a number of standard
struct file_operations defined on it. With respect to transporting raw
IR data to and fro, the essential fops are read, write and ioctl.
LIRC stands for Linux Infrared Remote Control. The LIRC device interface is
a bi-directional interface for transporting raw IR and decoded scancodes
data between userspace and kernelspace. Fundamentally, it is just a chardev
(/dev/lircX, for X = 0, 1, 2, ...), with a number of standard struct
file_operations defined on it. With respect to transporting raw IR and
decoded scancodes to and fro, the essential fops are read, write and ioctl.
Example dmesg output upon a driver registering w/LIRC:
@ -18,7 +19,7 @@ Example dmesg output upon a driver registering w/LIRC:
$ dmesg |grep lirc_dev
lirc_dev: IR Remote Control driver registered, major 248
rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0
rc rc0: lirc_dev: driver mceusb registered at minor = 0
What you should see for a chardev:
@ -36,6 +37,43 @@ LIRC modes
LIRC supports some modes of receiving and sending IR codes, as shown
on the following table.
.. _lirc-mode-scancode:
.. _lirc-scancode-flag-toggle:
.. _lirc-scancode-flag-repeat:
``LIRC_MODE_SCANCODE``
This mode is for both sending and receiving IR.
For transmitting (aka sending), create a ``struct lirc_scancode`` with
the desired scancode set in the ``scancode`` member, :c:type:`rc_proto`
set the IR protocol, and all other members set to 0. Write this struct to
the lirc device.
For receiving, you read ``struct lirc_scancode`` from the lirc device,
with ``scancode`` set to the received scancode and the IR protocol
:c:type:`rc_proto`. If the scancode maps to a valid key code, this is set
in the ``keycode`` field, else it is set to ``KEY_RESERVED``.
The ``flags`` can have ``LIRC_SCANCODE_FLAG_TOGGLE`` set if the toggle
bit is set in protocols that support it (e.g. rc-5 and rc-6), or
``LIRC_SCANCODE_FLAG_REPEAT`` for when a repeat is received for protocols
that support it (e.g. nec).
In the Sanyo and NEC protocol, if you hold a button on remote, rather than
repeating the entire scancode, the remote sends a shorter message with
no scancode, which just means button is held, a "repeat". When this is
received, the ``LIRC_SCANCODE_FLAG_REPEAT`` is set and the scancode and
keycode is repeated.
With nec, there is no way to distinguish "button hold" from "repeatedly
pressing the same button". The rc-5 and rc-6 protocols have a toggle bit.
When a button is released and pressed again, the toggle bit is inverted.
If the toggle bit is set, the ``LIRC_SCANCODE_FLAG_TOGGLE`` is set.
The ``timestamp`` field is filled with the time nanoseconds
(in ``CLOCK_MONOTONIC``) when the scancode was decoded.
.. _lirc-mode-mode2:
``LIRC_MODE_MODE2``
@ -72,21 +110,6 @@ on the following table.
this packet will be sent, with the number of microseconds with
no IR.
.. _lirc-mode-lirccode:
``LIRC_MODE_LIRCCODE``
This mode can be used for IR receive and send.
The IR signal is decoded internally by the receiver, or encoded by the
transmitter. The LIRC interface represents the scancode as byte string,
which might not be a u32, it can be any length. The value is entirely
driver dependent. This mode is used by some older lirc drivers.
The length of each code depends on the driver, which can be retrieved
with :ref:`lirc_get_length`. This length is used both
for transmitting and receiving IR.
.. _lirc-mode-pulse:
``LIRC_MODE_PULSE``
@ -99,3 +122,13 @@ on the following table.
of entries.
This mode is used only for IR send.
**************************
Remote Controller protocol
**************************
An enum :c:type:`rc_proto` in the :ref:`lirc_header` lists all the
supported IR protocols:
.. kernel-doc:: include/uapi/linux/lirc.h

1
Documentation/media/uapi/rc/lirc-func.rst
View file

@ -18,7 +18,6 @@ LIRC Function Reference
lirc-set-send-duty-cycle
lirc-get-timeout
lirc-set-rec-timeout
lirc-get-length
lirc-set-rec-carrier
lirc-set-rec-carrier-range
lirc-set-send-carrier

25
Documentation/media/uapi/rc/lirc-get-features.rst
View file

@ -55,15 +55,24 @@ LIRC features
``LIRC_CAN_REC_MODE2``
The driver is capable of receiving using
:ref:`LIRC_MODE_MODE2 <lirc-mode-MODE2>`.
This is raw IR driver for receiving. This means that
:ref:`LIRC_MODE_MODE2 <lirc-mode-MODE2>` is used. This also implies
that :ref:`LIRC_MODE_SCANCODE <lirc-mode-SCANCODE>` is also supported,
as long as the kernel is recent enough. Use the
:ref:`lirc_set_rec_mode` to switch modes.
.. _LIRC-CAN-REC-LIRCCODE:
``LIRC_CAN_REC_LIRCCODE``
The driver is capable of receiving using
:ref:`LIRC_MODE_LIRCCODE <lirc-mode-LIRCCODE>`.
Unused. Kept just to avoid breaking uAPI.
.. _LIRC-CAN-REC-SCANCODE:
``LIRC_CAN_REC_SCANCODE``
This is a scancode driver for receiving. This means that
:ref:`LIRC_MODE_SCANCODE <lirc-mode-SCANCODE>` is used.
.. _LIRC-CAN-SET-SEND-CARRIER:
@ -157,7 +166,10 @@ LIRC features
``LIRC_CAN_SEND_PULSE``
The driver supports sending (also called as IR blasting or IR TX) using
:ref:`LIRC_MODE_PULSE <lirc-mode-pulse>`.
:ref:`LIRC_MODE_PULSE <lirc-mode-pulse>`. This implies that
:ref:`LIRC_MODE_SCANCODE <lirc-mode-SCANCODE>` is also supported for
transmit, as long as the kernel is recent enough. Use the
:ref:`lirc_set_send_mode` to switch modes.
.. _LIRC-CAN-SEND-MODE2:
@ -170,8 +182,7 @@ LIRC features
``LIRC_CAN_SEND_LIRCCODE``
The driver supports sending (also called as IR blasting or IR TX) using
:ref:`LIRC_MODE_LIRCCODE <lirc-mode-LIRCCODE>`.
Unused. Kept just to avoid breaking uAPI.
Return Value

44
Documentation/media/uapi/rc/lirc-get-length.rst
View file

@ -1,44 +0,0 @@
.. -*- coding: utf-8; mode: rst -*-
.. _lirc_get_length:
*********************
ioctl LIRC_GET_LENGTH
*********************
Name
====
LIRC_GET_LENGTH - Retrieves the code length in bits.
Synopsis
========
.. c:function:: int ioctl( int fd, LIRC_GET_LENGTH, __u32 *length )
:name: LIRC_GET_LENGTH
Arguments
=========
``fd``
File descriptor returned by open().
``length``
length, in bits
Description
===========
Retrieves the code length in bits (only for
:ref:`LIRC_MODE_LIRCCODE <lirc-mode-lirccode>`).
Reads on the device must be done in blocks matching the bit count.
The bit could should be rounded up so that it matches full bytes.
Return Value
============
On success 0 is returned, on error -1 and the ``errno`` variable is set
appropriately. The generic error codes are described at the
:ref:`Generic Error Codes <gen-errors>` chapter.

45
Documentation/media/uapi/rc/lirc-get-rec-mode.rst
View file

@ -10,15 +10,15 @@ ioctls LIRC_GET_REC_MODE and LIRC_SET_REC_MODE
Name
====
LIRC_GET_REC_MODE/LIRC_SET_REC_MODE - Get/set supported receive modes.
LIRC_GET_REC_MODE/LIRC_SET_REC_MODE - Get/set current receive mode.
Synopsis
========
.. c:function:: int ioctl( int fd, LIRC_GET_REC_MODE, __u32 rx_modes)
.. c:function:: int ioctl( int fd, LIRC_GET_REC_MODE, __u32 *mode)
:name: LIRC_GET_REC_MODE
.. c:function:: int ioctl( int fd, LIRC_SET_REC_MODE, __u32 rx_modes)
.. c:function:: int ioctl( int fd, LIRC_SET_REC_MODE, __u32 *mode)
:name: LIRC_SET_REC_MODE
Arguments
@ -27,20 +27,41 @@ Arguments
``fd``
File descriptor returned by open().
``rx_modes``
Bitmask with the supported transmit modes.
``mode``
Mode used for receive.
Description
===========
Get/set supported receive modes. Only :ref:`LIRC_MODE_MODE2 <lirc-mode-mode2>`
and :ref:`LIRC_MODE_LIRCCODE <lirc-mode-lirccode>` are supported for IR
receive. Use :ref:`lirc_get_features` to find out which modes the driver
supports.
Get and set the current receive mode. Only
:ref:`LIRC_MODE_MODE2 <lirc-mode-mode2>` and
:ref:`LIRC_MODE_SCANCODE <lirc-mode-scancode>` are supported.
Use :ref:`lirc_get_features` to find out which modes the driver supports.
Return Value
============
On success 0 is returned, on error -1 and the ``errno`` variable is set
appropriately. The generic error codes are described at the
:ref:`Generic Error Codes <gen-errors>` chapter.
.. tabularcolumns:: |p{2.5cm}|p{15.0cm}|
.. flat-table::
:header-rows: 0
:stub-columns: 0
- .. row 1
- ``ENODEV``
- Device not available.
- .. row 2
- ``ENOTTY``
- Device does not support receiving.
- .. row 3
- ``EINVAL``
- Invalid mode or invalid mode for this device.

40
Documentation/media/uapi/rc/lirc-get-send-mode.rst
View file

@ -10,15 +10,15 @@ ioctls LIRC_GET_SEND_MODE and LIRC_SET_SEND_MODE
Name
====
LIRC_GET_SEND_MODE/LIRC_SET_SEND_MODE - Get/set supported transmit mode.
LIRC_GET_SEND_MODE/LIRC_SET_SEND_MODE - Get/set current transmit mode.
Synopsis
========
.. c:function:: int ioctl( int fd, LIRC_GET_SEND_MODE, __u32 *tx_modes )
.. c:function:: int ioctl( int fd, LIRC_GET_SEND_MODE, __u32 *mode )
:name: LIRC_GET_SEND_MODE
.. c:function:: int ioctl( int fd, LIRC_SET_SEND_MODE, __u32 *tx_modes )
.. c:function:: int ioctl( int fd, LIRC_SET_SEND_MODE, __u32 *mode )
:name: LIRC_SET_SEND_MODE
Arguments
@ -27,8 +27,8 @@ Arguments
``fd``
File descriptor returned by open().
``tx_modes``
Bitmask with the supported transmit modes.
``mode``
The mode used for transmitting.
Description
@ -37,13 +37,35 @@ Description
Get/set current transmit mode.
Only :ref:`LIRC_MODE_PULSE <lirc-mode-pulse>` and
:ref:`LIRC_MODE_LIRCCODE <lirc-mode-lirccode>` is supported by for IR send,
:ref:`LIRC_MODE_SCANCODE <lirc-mode-scancode>` are supported by for IR send,
depending on the driver. Use :ref:`lirc_get_features` to find out which
modes the driver supports.
Return Value
============
On success 0 is returned, on error -1 and the ``errno`` variable is set
appropriately. The generic error codes are described at the
:ref:`Generic Error Codes <gen-errors>` chapter.
.. tabularcolumns:: |p{2.5cm}|p{15.0cm}|
.. flat-table::
:header-rows: 0
:stub-columns: 0
- .. row 1
- ``ENODEV``
- Device not available.
- .. row 2
- ``ENOTTY``
- Device does not support transmitting.
- .. row 3
- ``EINVAL``
- Invalid mode or invalid mode for this device.

15
Documentation/media/uapi/rc/lirc-read.rst
View file

@ -45,13 +45,20 @@ descriptor ``fd`` into the buffer starting at ``buf``. If ``count`` is zero,
is greater than ``SSIZE_MAX``, the result is unspecified.
The exact format of the data depends on what :ref:`lirc_modes` a driver
uses. Use :ref:`lirc_get_features` to get the supported mode.
uses. Use :ref:`lirc_get_features` to get the supported mode, and use
:ref:`lirc_set_rec_mode` set the current active mode.
The generally preferred mode for receive is
:ref:`LIRC_MODE_MODE2 <lirc-mode-mode2>`,
in which packets containing an int value describing an IR signal are
The mode :ref:`LIRC_MODE_MODE2 <lirc-mode-mode2>` is for raw IR,
in which packets containing an unsigned int value describing an IR signal are
read from the chardev.
Alternatively, :ref:`LIRC_MODE_SCANCODE <lirc-mode-scancode>` can be available,
in this mode scancodes which are either decoded by software decoders, or
by hardware decoders. The :c:type:`rc_proto` member is set to the
protocol used for transmission, and ``scancode`` to the decoded scancode,
and the ``keycode`` set to the keycode or ``KEY_RESERVED``.
Return Value
============

19
Documentation/media/uapi/rc/lirc-write.rst
View file

@ -42,21 +42,32 @@ Description
referenced by the file descriptor ``fd`` from the buffer starting at
``buf``.
The exact format of the data depends on what mode a driver uses, use
:ref:`lirc_get_features` to get the supported mode.
The exact format of the data depends on what mode a driver is in, use
:ref:`lirc_get_features` to get the supported modes and use
:ref:`lirc_set_send_mode` set the mode.
When in :ref:`LIRC_MODE_PULSE <lirc-mode-PULSE>` mode, the data written to
the chardev is a pulse/space sequence of integer values. Pulses and spaces
are only marked implicitly by their position. The data must start and end
with a pulse, therefore, the data must always include an uneven number of
samples. The write function must block until the data has been transmitted
samples. The write function blocks until the data has been transmitted
by the hardware. If more data is provided than the hardware can send, the
driver returns ``EINVAL``.
When in :ref:`LIRC_MODE_SCANCODE <lirc-mode-scancode>` mode, one
``struct lirc_scancode`` must be written to the chardev at a time, else
``EINVAL`` is returned. Set the desired scancode in the ``scancode`` member,
and the protocol in the :c:type:`rc_proto`: member. All other members must be
set to 0, else ``EINVAL`` is returned. If there is no protocol encoder
for the protocol or the scancode is not valid for the specified protocol,
``EINVAL`` is returned. The write function blocks until the scancode
is transmitted by the hardware.
Return Value
============
On success, the number of bytes read is returned. It is not an error if
On success, the number of bytes written is returned. It is not an error if
this number is smaller than the number of bytes requested, or the amount
of data required for one frame. On error, -1 is returned, and the ``errno``
variable is set appropriately. The generic error codes are described at the

1
Documentation/media/uapi/v4l/meta-formats.rst
View file

@ -12,5 +12,6 @@ These formats are used for the :ref:`metadata` interface only.
.. toctree::
:maxdepth: 1
pixfmt-meta-uvc
pixfmt-meta-vsp1-hgo
pixfmt-meta-vsp1-hgt

51
Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst Normal file
View file

@ -0,0 +1,51 @@
.. -*- coding: utf-8; mode: rst -*-
.. _v4l2-meta-fmt-uvc:
*******************************
V4L2_META_FMT_UVC ('UVCH')
*******************************
UVC Payload Header Data
Description
===========
This format describes standard UVC metadata, extracted from UVC packet headers
and provided by the UVC driver through metadata video nodes. That data includes
exact copies of the standard part of UVC Payload Header contents and auxiliary
timing information, required for precise interpretation of timestamps, contained
in those headers. See section "2.4.3.3 Video and Still Image Payload Headers" of
the "UVC 1.5 Class specification" for details.
Each UVC payload header can be between 2 and 12 bytes large. Buffers can
contain multiple headers, if multiple such headers have been transmitted by the
camera for the respective frame. However, the driver may drop headers when the
buffer is full, when they contain no useful information (e.g. those without the
SCR field or with that field identical to the previous header), or generally to
perform rate limiting when the device sends a large number of headers.
Each individual block contains the following fields:
.. flat-table:: UVC Metadata Block
:widths: 1 4
:header-rows: 1
:stub-columns: 0
* - Field
- Description
* - __u64 ts;
- system timestamp in host byte order, measured by the driver upon
reception of the payload
* - __u16 sof;
- USB Frame Number in host byte order, also obtained by the driver as
close as possible to the above timestamp to enable correlation between
them
* - :cspan:`1` *The rest is an exact copy of the UVC payload header:*
* - __u8 length;
- length of the rest of the block, including this field
* - __u8 flags;
- Flags, indicating presence of other standard UVC fields
* - __u8 buf[];
- The rest of the header, possibly including UVC PTS and SCR fields

1
Documentation/media/uapi/v4l/pixfmt-rgb.rst
View file

@ -16,6 +16,7 @@ RGB Formats
pixfmt-srggb10p
pixfmt-srggb10alaw8
pixfmt-srggb10dpcm8
pixfmt-srggb10-ipu3
pixfmt-srggb12
pixfmt-srggb12p
pixfmt-srggb16

335
Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst Normal file
View file

@ -0,0 +1,335 @@
.. -*- coding: utf-8; mode: rst -*-
.. _v4l2-pix-fmt-ipu3-sbggr10:
.. _v4l2-pix-fmt-ipu3-sgbrg10:
.. _v4l2-pix-fmt-ipu3-sgrbg10:
.. _v4l2-pix-fmt-ipu3-srggb10:
**********************************************************************************************************************************************
V4L2_PIX_FMT_IPU3_SBGGR10 ('ip3b'), V4L2_PIX_FMT_IPU3_SGBRG10 ('ip3g'), V4L2_PIX_FMT_IPU3_SGRBG10 ('ip3G'), V4L2_PIX_FMT_IPU3_SRGGB10 ('ip3r')
**********************************************************************************************************************************************
10-bit Bayer formats
Description
===========
These four pixel formats are used by Intel IPU3 driver, they are raw
sRGB / Bayer formats with 10 bits per sample with every 25 pixels packed
to 32 bytes leaving 6 most significant bits padding in the last byte.
The format is little endian.
In other respects this format is similar to :ref:`V4L2-PIX-FMT-SRGGB10`.
Below is an example of a small image in V4L2_PIX_FMT_IPU3_SBGGR10 format.
**Byte Order.**
Each cell is one byte.
.. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}|p{4.0cm}|p{4.0cm}|
.. flat-table::
* - start + 0:
- B\ :sub:`0000low`
- G\ :sub:`0001low`\ (bits 7--2)
B\ :sub:`0000high`\ (bits 1--0)
- B\ :sub:`0002low`\ (bits 7--4)
G\ :sub:`0001high`\ (bits 3--0)
- G\ :sub:`0003low`\ (bits 7--6)
B\ :sub:`0002high`\ (bits 5--0)
* - start + 4:
- G\ :sub:`0003high`
- B\ :sub:`0004low`
- G\ :sub:`0005low`\ (bits 7--2)
B\ :sub:`0004high`\ (bits 1--0)
- B\ :sub:`0006low`\ (bits 7--4)
G\ :sub:`0005high`\ (bits 3--0)
* - start + 8:
- G\ :sub:`0007low`\ (bits 7--6)
B\ :sub:`0006high`\ (bits 5--0)
- G\ :sub:`0007high`
- B\ :sub:`0008low`
- G\ :sub:`0009low`\ (bits 7--2)
B\ :sub:`0008high`\ (bits 1--0)
* - start + 12:
- B\ :sub:`0010low`\ (bits 7--4)
G\ :sub:`0009high`\ (bits 3--0)
- G\ :sub:`0011low`\ (bits 7--6)
B\ :sub:`0010high`\ (bits 5--0)
- G\ :sub:`0011high`
- B\ :sub:`0012low`
* - start + 16:
- G\ :sub:`0013low`\ (bits 7--2)
B\ :sub:`0012high`\ (bits 1--0)
- B\ :sub:`0014low`\ (bits 7--4)
G\ :sub:`0013high`\ (bits 3--0)
- G\ :sub:`0015low`\ (bits 7--6)
B\ :sub:`0014high`\ (bits 5--0)
- G\ :sub:`0015high`
* - start + 20
- B\ :sub:`0016low`
- G\ :sub:`0017low`\ (bits 7--2)
B\ :sub:`0016high`\ (bits 1--0)
- B\ :sub:`0018low`\ (bits 7--4)
G\ :sub:`0017high`\ (bits 3--0)
- G\ :sub:`0019low`\ (bits 7--6)
B\ :sub:`0018high`\ (bits 5--0)
* - start + 24:
- G\ :sub:`0019high`
- B\ :sub:`0020low`
- G\ :sub:`0021low`\ (bits 7--2)
B\ :sub:`0020high`\ (bits 1--0)
- B\ :sub:`0022low`\ (bits 7--4)
G\ :sub:`0021high`\ (bits 3--0)
* - start + 28:
- G\ :sub:`0023low`\ (bits 7--6)
B\ :sub:`0022high`\ (bits 5--0)
- G\ :sub:`0023high`
- B\ :sub:`0024low`
- B\ :sub:`0024high`\ (bits 1--0)
* - start + 32:
- G\ :sub:`0100low`
- R\ :sub:`0101low`\ (bits 7--2)
G\ :sub:`0100high`\ (bits 1--0)
- G\ :sub:`0102low`\ (bits 7--4)
R\ :sub:`0101high`\ (bits 3--0)
- R\ :sub:`0103low`\ (bits 7--6)
G\ :sub:`0102high`\ (bits 5--0)
* - start + 36:
- R\ :sub:`0103high`
- G\ :sub:`0104low`
- R\ :sub:`0105low`\ (bits 7--2)
G\ :sub:`0104high`\ (bits 1--0)
- G\ :sub:`0106low`\ (bits 7--4)
R\ :sub:`0105high`\ (bits 3--0)
* - start + 40:
- R\ :sub:`0107low`\ (bits 7--6)
G\ :sub:`0106high`\ (bits 5--0)
- R\ :sub:`0107high`
- G\ :sub:`0108low`
- R\ :sub:`0109low`\ (bits 7--2)
G\ :sub:`0108high`\ (bits 1--0)
* - start + 44:
- G\ :sub:`0110low`\ (bits 7--4)
R\ :sub:`0109high`\ (bits 3--0)
- R\ :sub:`0111low`\ (bits 7--6)
G\ :sub:`0110high`\ (bits 5--0)
- R\ :sub:`0111high`
- G\ :sub:`0112low`
* - start + 48:
- R\ :sub:`0113low`\ (bits 7--2)
G\ :sub:`0112high`\ (bits 1--0)
- G\ :sub:`0114low`\ (bits 7--4)
R\ :sub:`0113high`\ (bits 3--0)
- R\ :sub:`0115low`\ (bits 7--6)
G\ :sub:`0114high`\ (bits 5--0)
- R\ :sub:`0115high`
* - start + 52:
- G\ :sub:`0116low`
- R\ :sub:`0117low`\ (bits 7--2)
G\ :sub:`0116high`\ (bits 1--0)
- G\ :sub:`0118low`\ (bits 7--4)
R\ :sub:`0117high`\ (bits 3--0)
- R\ :sub:`0119low`\ (bits 7--6)
G\ :sub:`0118high`\ (bits 5--0)
* - start + 56:
- R\ :sub:`0119high`
- G\ :sub:`0120low`
- R\ :sub:`0121low`\ (bits 7--2)
G\ :sub:`0120high`\ (bits 1--0)
- G\ :sub:`0122low`\ (bits 7--4)
R\ :sub:`0121high`\ (bits 3--0)
* - start + 60:
- R\ :sub:`0123low`\ (bits 7--6)
G\ :sub:`0122high`\ (bits 5--0)
- R\ :sub:`0123high`
- G\ :sub:`0124low`
- G\ :sub:`0124high`\ (bits 1--0)
* - start + 64:
- B\ :sub:`0200low`
- G\ :sub:`0201low`\ (bits 7--2)
B\ :sub:`0200high`\ (bits 1--0)
- B\ :sub:`0202low`\ (bits 7--4)
G\ :sub:`0201high`\ (bits 3--0)
- G\ :sub:`0203low`\ (bits 7--6)
B\ :sub:`0202high`\ (bits 5--0)
* - start + 68:
- G\ :sub:`0203high`
- B\ :sub:`0204low`
- G\ :sub:`0205low`\ (bits 7--2)
B\ :sub:`0204high`\ (bits 1--0)
- B\ :sub:`0206low`\ (bits 7--4)
G\ :sub:`0205high`\ (bits 3--0)
* - start + 72:
- G\ :sub:`0207low`\ (bits 7--6)
B\ :sub:`0206high`\ (bits 5--0)
- G\ :sub:`0207high`
- B\ :sub:`0208low`
- G\ :sub:`0209low`\ (bits 7--2)
B\ :sub:`0208high`\ (bits 1--0)
* - start + 76:
- B\ :sub:`0210low`\ (bits 7--4)
G\ :sub:`0209high`\ (bits 3--0)
- G\ :sub:`0211low`\ (bits 7--6)
B\ :sub:`0210high`\ (bits 5--0)
- G\ :sub:`0211high`
- B\ :sub:`0212low`
* - start + 80:
- G\ :sub:`0213low`\ (bits 7--2)
B\ :sub:`0212high`\ (bits 1--0)
- B\ :sub:`0214low`\ (bits 7--4)
G\ :sub:`0213high`\ (bits 3--0)
- G\ :sub:`0215low`\ (bits 7--6)
B\ :sub:`0214high`\ (bits 5--0)
- G\ :sub:`0215high`
* - start + 84:
- B\ :sub:`0216low`
- G\ :sub:`0217low`\ (bits 7--2)
B\ :sub:`0216high`\ (bits 1--0)
- B\ :sub:`0218low`\ (bits 7--4)
G\ :sub:`0217high`\ (bits 3--0)
- G\ :sub:`0219low`\ (bits 7--6)
B\ :sub:`0218high`\ (bits 5--0)
* - start + 88:
- G\ :sub:`0219high`
- B\ :sub:`0220low`
- G\ :sub:`0221low`\ (bits 7--2)
B\ :sub:`0220high`\ (bits 1--0)
- B\ :sub:`0222low`\ (bits 7--4)
G\ :sub:`0221high`\ (bits 3--0)
* - start + 92:
- G\ :sub:`0223low`\ (bits 7--6)
B\ :sub:`0222high`\ (bits 5--0)
- G\ :sub:`0223high`
- B\ :sub:`0224low`
- B\ :sub:`0224high`\ (bits 1--0)
* - start + 96:
- G\ :sub:`0300low`
- R\ :sub:`0301low`\ (bits 7--2)
G\ :sub:`0300high`\ (bits 1--0)
- G\ :sub:`0302low`\ (bits 7--4)
R\ :sub:`0301high`\ (bits 3--0)
- R\ :sub:`0303low`\ (bits 7--6)
G\ :sub:`0302high`\ (bits 5--0)
* - start + 100:
- R\ :sub:`0303high`
- G\ :sub:`0304low`
- R\ :sub:`0305low`\ (bits 7--2)
G\ :sub:`0304high`\ (bits 1--0)
- G\ :sub:`0306low`\ (bits 7--4)
R\ :sub:`0305high`\ (bits 3--0)
* - start + 104:
- R\ :sub:`0307low`\ (bits 7--6)
G\ :sub:`0306high`\ (bits 5--0)
- R\ :sub:`0307high`
- G\ :sub:`0308low`
- R\ :sub:`0309low`\ (bits 7--2)
G\ :sub:`0308high`\ (bits 1--0)
* - start + 108:
- G\ :sub:`0310low`\ (bits 7--4)
R\ :sub:`0309high`\ (bits 3--0)
- R\ :sub:`0311low`\ (bits 7--6)
G\ :sub:`0310high`\ (bits 5--0)
- R\ :sub:`0311high`
- G\ :sub:`0312low`
* - start + 112:
- R\ :sub:`0313low`\ (bits 7--2)
G\ :sub:`0312high`\ (bits 1--0)
- G\ :sub:`0314low`\ (bits 7--4)
R\ :sub:`0313high`\ (bits 3--0)
- R\ :sub:`0315low`\ (bits 7--6)
G\ :sub:`0314high`\ (bits 5--0)
- R\ :sub:`0315high`
* - start + 116:
- G\ :sub:`0316low`
- R\ :sub:`0317low`\ (bits 7--2)
G\ :sub:`0316high`\ (bits 1--0)
- G\ :sub:`0318low`\ (bits 7--4)
R\ :sub:`0317high`\ (bits 3--0)
- R\ :sub:`0319low`\ (bits 7--6)
G\ :sub:`0318high`\ (bits 5--0)
* - start + 120:
- R\ :sub:`0319high`
- G\ :sub:`0320low`
- R\ :sub:`0321low`\ (bits 7--2)
G\ :sub:`0320high`\ (bits 1--0)
- G\ :sub:`0322low`\ (bits 7--4)
R\ :sub:`0321high`\ (bits 3--0)
* - start + 124:
- R\ :sub:`0323low`\ (bits 7--6)
G\ :sub:`0322high`\ (bits 5--0)
- R\ :sub:`0323high`
- G\ :sub:`0324low`
- G\ :sub:`0324high`\ (bits 1--0)

2
Documentation/media/uapi/v4l/vidioc-g-dv-timings.rst
View file

@ -267,7 +267,7 @@ EBUSY
will also be cleared.
* - ``V4L2_DV_FL_HALF_LINE``
- Specific to interlaced formats: if set, then the vertical
frontporch of field 1 (aka the odd field) is really one half-line
backporch of field 1 (aka the odd field) is really one half-line
longer and the vertical backporch of field 2 (aka the even field)
is really one half-line shorter, so each field has exactly the
same number of half-lines. Whether half-lines can be detected or

7
Documentation/mips/AU1xxx_IDE.README
View file

@ -56,8 +56,6 @@ Following extra configs variables are introduced:
CONFIG_BLK_DEV_IDE_AU1XXX_PIO_DBDMA - enable the PIO+DBDMA mode
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA - enable the MWDMA mode
CONFIG_BLK_DEV_IDE_AU1XXX_BURSTABLE_ON - set Burstable FIFO in DBDMA
controller
SUPPORTED IDE MODES
@ -82,11 +80,9 @@ CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDE_AU1XXX=y
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
Also define 'IDE_AU1XXX_BURSTMODE' in 'drivers/ide/mips/au1xxx-ide.c' to enable
the burst support on DBDMA controller.
@ -94,16 +90,13 @@ the burst support on DBDMA controller.
If the used system need the USB support enable the following kernel configs for
high IDE to USB throughput.
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDE_AU1XXX=y
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
Also undefine 'IDE_AU1XXX_BURSTMODE' in 'drivers/ide/mips/au1xxx-ide.c' to
disable the burst support on DBDMA controller.

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

@ -508,7 +508,7 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max
min: Minimal size of receive buffer used by TCP sockets.
It is guaranteed to each TCP socket, even under moderate memory
pressure.
Default: 1 page
Default: 4K
default: initial size of receive buffer used by TCP sockets.
This value overrides net.core.rmem_default used by other protocols.
@ -667,7 +667,7 @@ tcp_window_scaling - BOOLEAN
tcp_wmem - vector of 3 INTEGERs: min, default, max
min: Amount of memory reserved for send buffers for TCP sockets.
Each TCP socket has rights to use it due to fact of its birth.
Default: 1 page
Default: 4K
default: initial size of send buffer used by TCP sockets. This
value overrides net.core.wmem_default used by other protocols.

1
Documentation/process/index.rst
View file

@ -24,6 +24,7 @@ Below are the essential guides that every developer should read.
development-process
submitting-patches
coding-style
maintainer-pgp-guide
email-clients
kernel-enforcement-statement
kernel-driver-statement

2
Documentation/process/kernel-docs.rst
View file

@ -58,7 +58,7 @@ On-line docs
* Title: **Linux Kernel Mailing List Glossary**
:Author: various
:URL: http://kernelnewbies.org/glossary/
:URL: https://kernelnewbies.org/KernelGlossary
:Date: rolling version
:Keywords: glossary, terms, linux-kernel.
:Description: From the introduction: "This glossary is intended as

929
Documentation/process/maintainer-pgp-guide.rst Normal file
View file

@ -0,0 +1,929 @@
.. _pgpguide:
===========================
Kernel Maintainer PGP guide
===========================
:Author: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
This document is aimed at Linux kernel developers, and especially at
subsystem maintainers. It contains a subset of information discussed in
the more general "`Protecting Code Integrity`_" guide published by the
Linux Foundation. Please read that document for more in-depth discussion
on some of the topics mentioned in this guide.
.. _`Protecting Code Integrity`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
The role of PGP in Linux Kernel development
===========================================
PGP helps ensure the integrity of the code that is produced by the Linux
kernel development community and, to a lesser degree, establish trusted
communication channels between developers via PGP-signed email exchange.
The Linux kernel source code is available in two main formats:
- Distributed source repositories (git)
- Periodic release snapshots (tarballs)
Both git repositories and tarballs carry PGP signatures of the kernel
developers who create official kernel releases. These signatures offer a
cryptographic guarantee that downloadable versions made available via
kernel.org or any other mirrors are identical to what these developers
have on their workstations. To this end:
- git repositories provide PGP signatures on all tags
- tarballs provide detached PGP signatures with all downloads
.. _devs_not_infra:
Trusting the developers, not infrastructure
-------------------------------------------
Ever since the 2011 compromise of core kernel.org systems, the main
operating principle of the Kernel Archives project has been to assume
that any part of the infrastructure can be compromised at any time. For
this reason, the administrators have taken deliberate steps to emphasize
that trust must always be placed with developers and never with the code
hosting infrastructure, regardless of how good the security practices
for the latter may be.
The above guiding principle is the reason why this guide is needed. We
want to make sure that by placing trust into developers we do not simply
shift the blame for potential future security incidents to someone else.
The goal is to provide a set of guidelines developers can use to create
a secure working environment and safeguard the PGP keys used to
establish the integrity of the Linux kernel itself.
.. _pgp_tools:
PGP tools
=========
Use GnuPG v2
------------
Your distro should already have GnuPG installed by default, you just
need to verify that you are using version 2.x and not the legacy 1.4
release -- many distributions still package both, with the default
``gpg`` command invoking GnuPG v.1. To check, run::
$ gpg --version | head -n1
If you see ``gpg (GnuPG) 1.4.x``, then you are using GnuPG v.1. Try the
``gpg2`` command (if you don't have it, you may need to install the
gnupg2 package)::
$ gpg2 --version | head -n1
If you see ``gpg (GnuPG) 2.x.x``, then you are good to go. This guide
will assume you have the version 2.2 of GnuPG (or later). If you are
using version 2.0 of GnuPG, then some of the commands in this guide will
not work, and you should consider installing the latest 2.2 version of
GnuPG. Versions of gnupg-2.1.11 and later should be compatible for the
purposes of this guide as well.
If you have both ``gpg`` and ``gpg2`` commands, you should make sure you
are always using GnuPG v2, not the legacy version. You can enforce this
by setting the appropriate alias::
$ alias gpg=gpg2
You can put that in your ``.bashrc`` to make sure it's always the case.
Configure gpg-agent options
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The GnuPG agent is a helper tool that will start automatically whenever
you use the ``gpg`` command and run in the background with the purpose
of caching the private key passphrase. There are two options you should
know in order to tweak when the passphrase should be expired from cache:
- ``default-cache-ttl`` (seconds): If you use the same key again before
the time-to-live expires, the countdown will reset for another period.
The default is 600 (10 minutes).
- ``max-cache-ttl`` (seconds): Regardless of how recently you've used
the key since initial passphrase entry, if the maximum time-to-live
countdown expires, you'll have to enter the passphrase again. The
default is 30 minutes.
If you find either of these defaults too short (or too long), you can
edit your ``~/.gnupg/gpg-agent.conf`` file to set your own values::
# set to 30 minutes for regular ttl, and 2 hours for max ttl
default-cache-ttl 1800
max-cache-ttl 7200
.. note::
It is no longer necessary to start gpg-agent manually at the
beginning of your shell session. You may want to check your rc files
to remove anything you had in place for older versions of GnuPG, as
it may not be doing the right thing any more.
Set up a refresh cronjob
~~~~~~~~~~~~~~~~~~~~~~~~
You will need to regularly refresh your keyring in order to get the
latest changes on other people's public keys, which is best done with a
daily cronjob::
@daily /usr/bin/gpg2 --refresh >/dev/null 2>&1
Check the full path to your ``gpg`` or ``gpg2`` command and use the
``gpg2`` command if regular ``gpg`` for you is the legacy GnuPG v.1.
.. _master_key:
Protect your master PGP key
===========================
This guide assumes that you already have a PGP key that you use for Linux
kernel development purposes. If you do not yet have one, please see the
"`Protecting Code Integrity`_" document mentioned earlier for guidance
on how to create a new one.
You should also make a new key if your current one is weaker than 2048 bits
(RSA).
Master key vs. Subkeys
----------------------
Subkeys are fully independent PGP keypairs that are tied to the "master"
key using certifying key signatures (certificates). It is important to
understand the following:
1. There are no technical differences between the "master key" and "subkeys."
2. At creation time, we assign functional limitations to each key by
giving it specific capabilities.
3. A PGP key can have 4 capabilities:
- **[S]** key can be used for signing
- **[E]** key can be used for encryption
- **[A]** key can be used for authentication
- **[C]** key can be used for certifying other keys
4. A single key may have multiple capabilities.
5. A subkey is fully independent from the master key. A message
encrypted to a subkey cannot be decrypted with the master key. If you
lose your private subkey, it cannot be recreated from the master key
in any way.
The key carrying the **[C]** (certify) capability is considered the
"master" key because it is the only key that can be used to indicate
relationship with other keys. Only the **[C]** key can be used to:
- add or revoke other keys (subkeys) with S/E/A capabilities
- add, change or revoke identities (uids) associated with the key
- add or change the expiration date on itself or any subkey
- sign other people's keys for web of trust purposes
By default, GnuPG creates the following when generating new keys:
- A master key carrying both Certify and Sign capabilities (**[SC]**)
- A separate subkey with the Encryption capability (**[E]**)
If you used the default parameters when generating your key, then that
is what you will have. You can verify by running ``gpg --list-secret-keys``,
for example::
sec rsa2048 2018-01-23 [SC] [expires: 2020-01-23]
000000000000000000000000AAAABBBBCCCCDDDD
uid [ultimate] Alice Dev <adev@kernel.org>
ssb rsa2048 2018-01-23 [E] [expires: 2020-01-23]
Any key carrying the **[C]** capability is your master key, regardless
of any other capabilities it may have assigned to it.
The long line under the ``sec`` entry is your key fingerprint --
whenever you see ``[fpr]`` in the examples below, that 40-character
string is what it refers to.
Ensure your passphrase is strong
--------------------------------
GnuPG uses passphrases to encrypt your private keys before storing them on
disk. This way, even if your ``.gnupg`` directory is leaked or stolen in
its entirety, the attackers cannot use your private keys without first
obtaining the passphrase to decrypt them.
It is absolutely essential that your private keys are protected by a
strong passphrase. To set it or change it, use::
$ gpg --change-passphrase [fpr]
Create a separate Signing subkey
--------------------------------
Our goal is to protect your master key by moving it to offline media, so
if you only have a combined **[SC]** key, then you should create a separate
signing subkey::
$ gpg --quick-add-key [fpr] ed25519 sign
Remember to tell the keyservers about this change, so others can pull down
your new subkey::
$ gpg --send-key [fpr]
.. note:: ECC support in GnuPG
GnuPG 2.1 and later has full support for Elliptic Curve
Cryptography, with ability to combine ECC subkeys with traditional
RSA master keys. The main upside of ECC cryptography is that it is
much faster computationally and creates much smaller signatures when
compared byte for byte with 2048+ bit RSA keys. Unless you plan on
using a smartcard device that does not support ECC operations, we
recommend that you create an ECC signing subkey for your kernel
work.
If for some reason you prefer to stay with RSA subkeys, just replace
"ed25519" with "rsa2048" in the above command.
Back up your master key for disaster recovery
---------------------------------------------
The more signatures you have on your PGP key from other developers, the
more reasons you have to create a backup version that lives on something
other than digital media, for disaster recovery reasons.
The best way to create a printable hardcopy of your private key is by
using the ``paperkey`` software written for this very purpose. See ``man
paperkey`` for more details on the output format and its benefits over
other solutions. Paperkey should already be packaged for most
distributions.
Run the following command to create a hardcopy backup of your private
key::
$ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
Print out that file (or pipe the output straight to lpr), then take a
pen and write your passphrase on the margin of the paper. **This is
strongly recommended** because the key printout is still encrypted with
that passphrase, and if you ever change it you will not remember what it
used to be when you had created the backup -- *guaranteed*.
Put the resulting printout and the hand-written passphrase into an envelope
and store in a secure and well-protected place, preferably away from your
home, such as your bank vault.
.. note::
Your printer is probably no longer a simple dumb device connected to
your parallel port, but since the output is still encrypted with
your passphrase, printing out even to "cloud-integrated" modern
printers should remain a relatively safe operation. One option is to
change the passphrase on your master key immediately after you are
done with paperkey.
Back up your whole GnuPG directory
----------------------------------
.. warning::
**!!!Do not skip this step!!!**
It is important to have a readily available backup of your PGP keys
should you need to recover them. This is different from the
disaster-level preparedness we did with ``paperkey``. You will also rely
on these external copies whenever you need to use your Certify key --
such as when making changes to your own key or signing other people's
keys after conferences and summits.
Start by getting a small USB "thumb" drive (preferably two!) that you
will use for backup purposes. You will need to encrypt them using LUKS
-- refer to your distro's documentation on how to accomplish this.
For the encryption passphrase, you can use the same one as on your
master key.
Once the encryption process is over, re-insert the USB drive and make
sure it gets properly mounted. Copy your entire ``.gnupg`` directory
over to the encrypted storage::
$ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
You should now test to make sure everything still works::
$ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
If you don't get any errors, then you should be good to go. Unmount the
USB drive, distinctly label it so you don't blow it away next time you
need to use a random USB drive, and put in a safe place -- but not too
far away, because you'll need to use it every now and again for things
like editing identities, adding or revoking subkeys, or signing other
people's keys.
Remove the master key from your homedir
----------------------------------------
The files in our home directory are not as well protected as we like to
think. They can be leaked or stolen via many different means:
- by accident when making quick homedir copies to set up a new workstation
- by systems administrator negligence or malice
- via poorly secured backups
- via malware in desktop apps (browsers, pdf viewers, etc)
- via coercion when crossing international borders
Protecting your key with a good passphrase greatly helps reduce the risk
of any of the above, but passphrases can be discovered via keyloggers,
shoulder-surfing, or any number of other means. For this reason, the
recommended setup is to remove your master key from your home directory
and store it on offline storage.
.. warning::
Please see the previous section and make sure you have backed up
your GnuPG directory in its entirety. What we are about to do will
render your key useless if you do not have a usable backup!
First, identify the keygrip of your master key::
$ gpg --with-keygrip --list-key [fpr]
The output will be something like this::
pub rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
000000000000000000000000AAAABBBBCCCCDDDD
Keygrip = 1111000000000000000000000000000000000000
uid [ultimate] Alice Dev <adev@kernel.org>
sub rsa2048 2018-01-24 [E] [expires: 2020-01-24]
Keygrip = 2222000000000000000000000000000000000000
sub ed25519 2018-01-24 [S]
Keygrip = 3333000000000000000000000000000000000000
Find the keygrip entry that is beneath the ``pub`` line (right under the
master key fingerprint). This will correspond directly to a file in your
``~/.gnupg`` directory::
$ cd ~/.gnupg/private-keys-v1.d
$ ls
1111000000000000000000000000000000000000.key
2222000000000000000000000000000000000000.key
3333000000000000000000000000000000000000.key
All you have to do is simply remove the .key file that corresponds to
the master keygrip::
$ cd ~/.gnupg/private-keys-v1.d
$ rm 1111000000000000000000000000000000000000.key
Now, if you issue the ``--list-secret-keys`` command, it will show that
the master key is missing (the ``#`` indicates it is not available)::
$ gpg --list-secret-keys
sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
000000000000000000000000AAAABBBBCCCCDDDD
uid [ultimate] Alice Dev <adev@kernel.org>
ssb rsa2048 2018-01-24 [E] [expires: 2020-01-24]
ssb ed25519 2018-01-24 [S]
You should also remove any ``secring.gpg`` files in the ``~/.gnupg``
directory, which are left over from earlier versions of GnuPG.
If you don't have the "private-keys-v1.d" directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you do not have a ``~/.gnupg/private-keys-v1.d`` directory, then your
secret keys are still stored in the legacy ``secring.gpg`` file used by
GnuPG v1. Making any changes to your key, such as changing the
passphrase or adding a subkey, should automatically convert the old
``secring.gpg`` format to use ``private-keys-v1.d`` instead.
Once you get that done, make sure to delete the obsolete ``secring.gpg``
file, which still contains your private keys.
.. _smartcards:
Move the subkeys to a dedicated crypto device
=============================================
Even though the master key is now safe from being leaked or stolen, the
subkeys are still in your home directory. Anyone who manages to get
their hands on those will be able to decrypt your communication or fake
your signatures (if they know the passphrase). Furthermore, each time a
GnuPG operation is performed, the keys are loaded into system memory and
can be stolen from there by sufficiently advanced malware (think
Meltdown and Spectre).
The best way to completely protect your keys is to move them to a
specialized hardware device that is capable of smartcard operations.
The benefits of smartcards
--------------------------
A smartcard contains a cryptographic chip that is capable of storing
private keys and performing crypto operations directly on the card
itself. Because the key contents never leave the smartcard, the
operating system of the computer into which you plug in the hardware
device is not able to retrieve the private keys themselves. This is very
different from the encrypted USB storage device we used earlier for
backup purposes -- while that USB device is plugged in and mounted, the
operating system is able to access the private key contents.
Using external encrypted USB media is not a substitute to having a
smartcard-capable device.
Available smartcard devices
---------------------------
Unless all your laptops and workstations have smartcard readers, the
easiest is to get a specialized USB device that implements smartcard
functionality. There are several options available:
- `Nitrokey Start`_: Open hardware and Free Software, based on FSI
Japan's `Gnuk`_. Offers support for ECC keys, but fewest security
features (such as resistance to tampering or some side-channel
attacks).
- `Nitrokey Pro`_: Similar to the Nitrokey Start, but more
tamper-resistant and offers more security features, but no ECC
support.
- `Yubikey 4`_: proprietary hardware and software, but cheaper than
Nitrokey Pro and comes available in the USB-C form that is more useful
with newer laptops. Offers additional security features such as FIDO
U2F, but no ECC.
`LWN has a good review`_ of some of the above models, as well as several
others. If you want to use ECC keys, your best bet among commercially
available devices is the Nitrokey Start.
.. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
.. _`Nitrokey Pro`: https://shop.nitrokey.com/shop/product/nitrokey-pro-3
.. _`Yubikey 4`: https://www.yubico.com/product/yubikey-4-series/
.. _Gnuk: http://www.fsij.org/doc-gnuk/
.. _`LWN has a good review`: https://lwn.net/Articles/736231/
Configure your smartcard device
-------------------------------
Your smartcard device should Just Work (TM) the moment you plug it into
any modern Linux workstation. You can verify it by running::
$ gpg --card-status
If you see full smartcard details, then you are good to go.
Unfortunately, troubleshooting all possible reasons why things may not
be working for you is way beyond the scope of this guide. If you are
having trouble getting the card to work with GnuPG, please seek help via
usual support channels.
To configure your smartcard, you will need to use the GnuPG menu system, as
there are no convenient command-line switches::
$ gpg --card-edit
[...omitted...]
gpg/card> admin
Admin commands are allowed
gpg/card> passwd
You should set the user PIN (1), Admin PIN (3), and the Reset Code (4).
Please make sure to record and store these in a safe place -- especially
the Admin PIN and the Reset Code (which allows you to completely wipe
the smartcard). You so rarely need to use the Admin PIN, that you will
inevitably forget what it is if you do not record it.
Getting back to the main card menu, you can also set other values (such
as name, sex, login data, etc), but it's not necessary and will
additionally leak information about your smartcard should you lose it.
.. note::
Despite having the name "PIN", neither the user PIN nor the admin
PIN on the card need to be numbers.
Move the subkeys to your smartcard
----------------------------------
Exit the card menu (using "q") and save all changes. Next, let's move
your subkeys onto the smartcard. You will need both your PGP key
passphrase and the admin PIN of the card for most operations::
$ gpg --edit-key [fpr]
Secret subkeys are available.
pub rsa2048/AAAABBBBCCCCDDDD
created: 2018-01-23 expires: 2020-01-23 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/1111222233334444
created: 2018-01-23 expires: never usage: E
ssb ed25519/5555666677778888
created: 2017-12-07 expires: never usage: S
[ultimate] (1). Alice Dev <adev@kernel.org>
gpg>
Using ``--edit-key`` puts us into the menu mode again, and you will
notice that the key listing is a little different. From here on, all
commands are done from inside this menu mode, as indicated by ``gpg>``.
First, let's select the key we'll be putting onto the card -- you do
this by typing ``key 1`` (it's the first one in the listing, the **[E]**
subkey)::
gpg> key 1
In the output, you should now see ``ssb*`` on the **[E]** key. The ``*``
indicates which key is currently "selected." It works as a *toggle*,
meaning that if you type ``key 1`` again, the ``*`` will disappear and
the key will not be selected any more.
Now, let's move that key onto the smartcard::
gpg> keytocard
Please select where to store the key:
(2) Encryption key
Your selection? 2
Since it's our **[E]** key, it makes sense to put it into the Encryption
slot. When you submit your selection, you will be prompted first for
your PGP key passphrase, and then for the admin PIN. If the command
returns without an error, your key has been moved.
**Important**: Now type ``key 1`` again to unselect the first key, and
``key 2`` to select the **[S]** key::
gpg> key 1
gpg> key 2
gpg> keytocard
Please select where to store the key:
(1) Signature key
(3) Authentication key
Your selection? 1
You can use the **[S]** key both for Signature and Authentication, but
we want to make sure it's in the Signature slot, so choose (1). Once
again, if your command returns without an error, then the operation was
successful::
gpg> q
Save changes? (y/N) y
Saving the changes will delete the keys you moved to the card from your
home directory (but it's okay, because we have them in our backups
should we need to do this again for a replacement smartcard).
Verifying that the keys were moved
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you perform ``--list-secret-keys`` now, you will see a subtle
difference in the output::
$ gpg --list-secret-keys
sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
000000000000000000000000AAAABBBBCCCCDDDD
uid [ultimate] Alice Dev <adev@kernel.org>
ssb> rsa2048 2018-01-24 [E] [expires: 2020-01-24]
ssb> ed25519 2018-01-24 [S]
The ``>`` in the ``ssb>`` output indicates that the subkey is only
available on the smartcard. If you go back into your secret keys
directory and look at the contents there, you will notice that the
``.key`` files there have been replaced with stubs::
$ cd ~/.gnupg/private-keys-v1.d
$ strings *.key | grep 'private-key'
The output should contain ``shadowed-private-key`` to indicate that
these files are only stubs and the actual content is on the smartcard.
Verifying that the smartcard is functioning
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To verify that the smartcard is working as intended, you can create a
signature::
$ echo "Hello world" | gpg --clearsign > /tmp/test.asc
$ gpg --verify /tmp/test.asc
This should ask for your smartcard PIN on your first command, and then
show "Good signature" after you run ``gpg --verify``.
Congratulations, you have successfully made it extremely difficult to
steal your digital developer identity!
Other common GnuPG operations
-----------------------------
Here is a quick reference for some common operations you'll need to do
with your PGP key.
Mounting your master key offline storage
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You will need your master key for any of the operations below, so you
will first need to mount your backup offline storage and tell GnuPG to
use it::
$ export GNUPGHOME=/media/disk/foo/gnupg-backup
$ gpg --list-secret-keys
You want to make sure that you see ``sec`` and not ``sec#`` in the
output (the ``#`` means the key is not available and you're still using
your regular home directory location).
Extending key expiration date
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The master key has the default expiration date of 2 years from the date
of creation. This is done both for security reasons and to make obsolete
keys eventually disappear from keyservers.
To extend the expiration on your key by a year from current date, just
run::
$ gpg --quick-set-expire [fpr] 1y
You can also use a specific date if that is easier to remember (e.g.
your birthday, January 1st, or Canada Day)::
$ gpg --quick-set-expire [fpr] 2020-07-01
Remember to send the updated key back to keyservers::
$ gpg --send-key [fpr]
Updating your work directory after any changes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After you make any changes to your key using the offline storage, you will
want to import these changes back into your regular working directory::
$ gpg --export | gpg --homedir ~/.gnupg --import
$ unset GNUPGHOME
Using PGP with Git
==================
One of the core features of Git is its decentralized nature -- once a
repository is cloned to your system, you have full history of the
project, including all of its tags, commits and branches. However, with
hundreds of cloned repositories floating around, how does anyone verify
that their copy of linux.git has not been tampered with by a malicious
third party?
Or what happens if a backdoor is discovered in the code and the "Author"
line in the commit says it was done by you, while you're pretty sure you
had `nothing to do with it`_?
To address both of these issues, Git introduced PGP integration. Signed
tags prove the repository integrity by assuring that its contents are
exactly the same as on the workstation of the developer who created the
tag, while signed commits make it nearly impossible for someone to
impersonate you without having access to your PGP keys.
.. _`nothing to do with it`: https://github.com/jayphelps/git-blame-someone-else
Configure git to use your PGP key
---------------------------------
If you only have one secret key in your keyring, then you don't really
need to do anything extra, as it becomes your default key. However, if
you happen to have multiple secret keys, you can tell git which key
should be used (``[fpr]`` is the fingerprint of your key)::
$ git config --global user.signingKey [fpr]
**IMPORTANT**: If you have a distinct ``gpg2`` command, then you should
tell git to always use it instead of the legacy ``gpg`` from version 1::
$ git config --global gpg.program gpg2
How to work with signed tags
----------------------------
To create a signed tag, simply pass the ``-s`` switch to the tag
command::
$ git tag -s [tagname]
Our recommendation is to always sign git tags, as this allows other
developers to ensure that the git repository they are pulling from has
not been maliciously altered.
How to verify signed tags
~~~~~~~~~~~~~~~~~~~~~~~~~
To verify a signed tag, simply use the ``verify-tag`` command::
$ git verify-tag [tagname]
If you are pulling a tag from another fork of the project repository,
git should automatically verify the signature at the tip you're pulling
and show you the results during the merge operation::
$ git pull [url] tags/sometag
The merge message will contain something like this::
Merge tag 'sometag' of [url]
[Tag message]
# gpg: Signature made [...]
# gpg: Good signature from [...]
If you are verifying someone else's git tag, then you will need to
import their PGP key. Please refer to the
":ref:`verify_identities`" section below.
Configure git to always sign annotated tags
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chances are, if you're creating an annotated tag, you'll want to sign
it. To force git to always sign annotated tags, you can set a global
configuration option::
$ git config --global tag.forceSignAnnotated true
How to work with signed commits
-------------------------------
It is easy to create signed commits, but it is much more difficult to
use them in Linux kernel development, since it relies on patches sent to
the mailing list, and this workflow does not preserve PGP commit
signatures. Furthermore, when rebasing your repository to match
upstream, even your own PGP commit signatures will end up discarded. For
this reason, most kernel developers don't bother signing their commits
and will ignore signed commits in any external repositories that they
rely upon in their work.
However, if you have your working git tree publicly available at some
git hosting service (kernel.org, infradead.org, ozlabs.org, or others),
then the recommendation is that you sign all your git commits even if
upstream developers do not directly benefit from this practice.
We recommend this for the following reasons:
1. Should there ever be a need to perform code forensics or track code
provenance, even externally maintained trees carrying PGP commit
signatures will be valuable for such purposes.
2. If you ever need to re-clone your local repository (for example,
after a disk failure), this lets you easily verify the repository
integrity before resuming your work.
3. If someone needs to cherry-pick your commits, this allows them to
quickly verify their integrity before applying them.
Creating signed commits
~~~~~~~~~~~~~~~~~~~~~~~
To create a signed commit, you just need to pass the ``-S`` flag to the
``git commit`` command (it's capital ``-S`` due to collision with
another flag)::
$ git commit -S
Configure git to always sign commits
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can tell git to always sign commits::
git config --global commit.gpgSign true
.. note::
Make sure you configure ``gpg-agent`` before you turn this on.
.. _verify_identities:
How to verify kernel developer identities
=========================================
Signing tags and commits is easy, but how does one go about verifying
that the key used to sign something belongs to the actual kernel
developer and not to a malicious imposter?
Configure auto-key-retrieval using WKD and DANE
-----------------------------------------------
If you are not already someone with an extensive collection of other
developers' public keys, then you can jumpstart your keyring by relying
on key auto-discovery and auto-retrieval. GnuPG can piggyback on other
delegated trust technologies, namely DNSSEC and TLS, to get you going if
the prospect of starting your own Web of Trust from scratch is too
daunting.
Add the following to your ``~/.gnupg/gpg.conf``::
auto-key-locate wkd,dane,local
auto-key-retrieve
DNS-Based Authentication of Named Entities ("DANE") is a method for
publishing public keys in DNS and securing them using DNSSEC signed
zones. Web Key Directory ("WKD") is the alternative method that uses
https lookups for the same purpose. When using either DANE or WKD for
looking up public keys, GnuPG will validate DNSSEC or TLS certificates,
respectively, before adding auto-retrieved public keys to your local
keyring.
Kernel.org publishes the WKD for all developers who have kernel.org
accounts. Once you have the above changes in your ``gpg.conf``, you can
auto-retrieve the keys for Linus Torvalds and Greg Kroah-Hartman (if you
don't already have them)::
$ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
If you have a kernel.org account, then you should `add the kernel.org
UID to your key`_ to make WKD more useful to other kernel developers.
.. _`add the kernel.org UID to your key`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
Web of Trust (WOT) vs. Trust on First Use (TOFU)
------------------------------------------------
PGP incorporates a trust delegation mechanism known as the "Web of
Trust." At its core, this is an attempt to replace the need for
centralized Certification Authorities of the HTTPS/TLS world. Instead of
various software makers dictating who should be your trusted certifying
entity, PGP leaves this responsibility to each user.
Unfortunately, very few people understand how the Web of Trust works.
While it remains an important aspect of the OpenPGP specification,
recent versions of GnuPG (2.2 and above) have implemented an alternative
mechanism called "Trust on First Use" (TOFU). You can think of TOFU as
"the SSH-like approach to trust." With SSH, the first time you connect
to a remote system, its key fingerprint is recorded and remembered. If
the key changes in the future, the SSH client will alert you and refuse
to connect, forcing you to make a decision on whether you choose to
trust the changed key or not. Similarly, the first time you import
someone's PGP key, it is assumed to be valid. If at any point in the
future GnuPG comes across another key with the same identity, both the
previously imported key and the new key will be marked as invalid and
you will need to manually figure out which one to keep.
We recommend that you use the combined TOFU+PGP trust model (which is
the new default in GnuPG v2). To set it, add (or modify) the
``trust-model`` setting in ``~/.gnupg/gpg.conf``::
trust-model tofu+pgp
How to use keyservers (more) safely
-----------------------------------
If you get a "No public key" error when trying to validate someone's
tag, then you should attempt to lookup that key using a keyserver. It is
important to keep in mind that there is absolutely no guarantee that the
key you retrieve from PGP keyservers belongs to the actual person --
that much is by design. You are supposed to use the Web of Trust to
establish key validity.
How to properly maintain the Web of Trust is beyond the scope of this
document, simply because doing it properly requires both effort and
dedication that tends to be beyond the caring threshold of most human
beings. Here are some shortcuts that will help you reduce the risk of
importing a malicious key.
First, let's say you've tried to run ``git verify-tag`` but it returned
an error saying the key is not found::
$ git verify-tag sunxi-fixes-for-4.15-2
gpg: Signature made Sun 07 Jan 2018 10:51:55 PM EST
gpg: using RSA key DA73759BF8619E484E5A3B47389A54219C0F2430
gpg: issuer "wens@...org"
gpg: Can't check signature: No public key
Let's query the keyserver for more info about that key fingerprint (the
fingerprint probably belongs to a subkey, so we can't use it directly
without finding out the ID of the master key it is associated with)::
$ gpg --search DA73759BF8619E484E5A3B47389A54219C0F2430
gpg: data source: hkp://keys.gnupg.net
(1) Chen-Yu Tsai <wens@...org>
4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires: 2019-03-15
Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430". Enter number(s), N)ext, or Q)uit > q
Locate the ID of the master key in the output, in our example
``C94035C21B4F2AEB``. Now display the key of Linus Torvalds that you
have on your keyring::
$ gpg --list-key torvalds@kernel.org
pub rsa2048 2011-09-20 [SC]
ABAF11C65A2970B130ABE3C479BE3E4300411886
uid [ unknown] Linus Torvalds <torvalds@kernel.org>
sub rsa2048 2011-09-20 [E]
Next, open the `PGP pathfinder`_. In the "From" field, paste the key
fingerprint of Linus Torvalds from the output above. In the "To" field,
paste they key-id you found via ``gpg --search`` of the unknown key, and
check the results:
- `Finding paths to Linus`_
If you get a few decent trust paths, then it's a pretty good indication
that it is a valid key. You can add it to your keyring from the
keyserver now::
$ gpg --recv-key C94035C21B4F2AEB
This process is not perfect, and you are obviously trusting the
administrators of the PGP Pathfinder service to not be malicious (in
fact, this goes against :ref:`devs_not_infra`). However, if you
do not carefully maintain your own web of trust, then it is a marked
improvement over blindly trusting keyservers.
.. _`PGP pathfinder`: https://pgp.cs.uu.nl/
.. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html

2
Documentation/sysctl/user.txt
View file

@ -3,7 +3,7 @@ Documentation for /proc/sys/user/* kernel version 4.9.0
==============================================================
This file contains the documetation for the sysctl files in
This file contains the documentation for the sysctl files in
/proc/sys/user.
The files in this directory can be used to override the default

23
Documentation/watchdog/watchdog-parameters.txt
View file

@ -40,11 +40,6 @@ margin: Watchdog margin in seconds (default=60)
nowayout: Disable watchdog shutdown on close
(default=kernel config parameter)
-------------------------------------------------
at32ap700x_wdt:
timeout: Timeout value. Limited to be 1 or 2 seconds. (default=2)
nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
-------------------------------------------------
at91rm9200_wdt:
wdt_time: Watchdog time in seconds. (default=5)
nowayout: Watchdog cannot be stopped once started
@ -162,11 +157,6 @@ testmode: Watchdog test mode (1 = no reboot), default=0
nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
-------------------------------------------------
ixp2000_wdt:
heartbeat: Watchdog heartbeat in seconds (default 60s)
nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
-------------------------------------------------
ixp4xx_wdt:
heartbeat: Watchdog heartbeat in seconds (default 60s)
nowayout: Watchdog cannot be stopped once started
@ -381,19 +371,6 @@ timeout: Watchdog timeout in seconds. 1 <= timeout <= 255, default=60.
nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
-------------------------------------------------
w83697hf_wdt:
wdt_io: w83697hf/hg WDT io port (default 0x2e, 0 = autodetect)
timeout: Watchdog timeout in seconds. 1<= timeout <=255 (default=60)
nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
early_disable: Watchdog gets disabled at boot time (default=1)
-------------------------------------------------
w83697ug_wdt:
wdt_io: w83697ug/uf WDT io port (default 0x2e)
timeout: Watchdog timeout in seconds. 1<= timeout <=255 (default=60)
nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
-------------------------------------------------
w83877f_wdt:
timeout: Watchdog timeout in seconds. (1<=timeout<=3600, default=30)
nowayout: Watchdog cannot be stopped once started

148
MAINTAINERS
View file

@ -903,7 +903,6 @@ L: devel@driverdev.osuosl.org
S: Supported
F: drivers/staging/android/ion
F: drivers/staging/android/uapi/ion.h
F: drivers/staging/android/uapi/ion_test.h
AOA (Apple Onboard Audio) ALSA DRIVER
M: Johannes Berg <johannes@sipsolutions.net>
@ -1308,7 +1307,6 @@ M: Russell King <linux@armlinux.org.uk>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.armlinux.org.uk/~rmk/linux-arm.git clkdev
F: arch/arm/include/asm/clkdev.h
F: drivers/clk/clkdev.c
ARM/COMPULAB CM-X270/EM-X270 and CM-X300 MACHINE SUPPORT
@ -1360,7 +1358,7 @@ F: Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt
F: Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
F: Documentation/devicetree/bindings/rtc/faraday,ftrtc010.txt
F: arch/arm/mach-gemini/
F: drivers/net/ethernet/cortina/gemini/*
F: drivers/net/ethernet/cortina/
F: drivers/pinctrl/pinctrl-gemini.c
F: drivers/rtc/rtc-ftrtc010.c
@ -1737,9 +1735,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-oxnas@lists.tuxfamily.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-oxnas/
F: arch/arm/boot/dts/ox8*.dtsi
F: arch/arm/boot/dts/wd-mbwe.dts
F: arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
F: arch/arm/boot/dts/ox8*.dts*
N: oxnas
ARM/PALM TREO SUPPORT
@ -1747,8 +1743,7 @@ M: Tomas Cech <sleep_walker@suse.com>
L: linux-arm-kernel@lists.infradead.org
W: http://hackndev.com
S: Maintained
F: arch/arm/mach-pxa/include/mach/palmtreo.h
F: arch/arm/mach-pxa/palmtreo.c
F: arch/arm/mach-pxa/palmtreo.*
ARM/PALMTX,PALMT5,PALMLD,PALMTE2,PALMTC SUPPORT
M: Marek Vasut <marek.vasut@gmail.com>
@ -1757,12 +1752,10 @@ W: http://hackndev.com
S: Maintained
F: arch/arm/mach-pxa/include/mach/palmtx.h
F: arch/arm/mach-pxa/palmtx.c
F: arch/arm/mach-pxa/include/mach/palmt5.h
F: arch/arm/mach-pxa/palmt5.c
F: arch/arm/mach-pxa/palmt5.*
F: arch/arm/mach-pxa/include/mach/palmld.h
F: arch/arm/mach-pxa/palmld.c
F: arch/arm/mach-pxa/include/mach/palmte2.h
F: arch/arm/mach-pxa/palmte2.c
F: arch/arm/mach-pxa/palmte2.*
F: arch/arm/mach-pxa/include/mach/palmtc.h
F: arch/arm/mach-pxa/palmtc.c
@ -1771,8 +1764,7 @@ M: Sergey Lapin <slapin@ossfans.org>
L: linux-arm-kernel@lists.infradead.org
W: http://hackndev.com
S: Maintained
F: arch/arm/mach-pxa/include/mach/palmz72.h
F: arch/arm/mach-pxa/palmz72.c
F: arch/arm/mach-pxa/palmz72.*
ARM/PLEB SUPPORT
M: Peter Chubb <pleb@gelato.unsw.edu.au>
@ -1801,7 +1793,6 @@ F: drivers/clk/qcom/
F: drivers/dma/qcom/
F: drivers/soc/qcom/
F: drivers/spi/spi-qup.c
F: drivers/tty/serial/msm_serial.h
F: drivers/tty/serial/msm_serial.c
F: drivers/*/pm8???-*
F: drivers/mfd/ssbi.c
@ -2228,14 +2219,6 @@ L: linux-leds@vger.kernel.org
S: Maintained
F: drivers/leds/leds-as3645a.c
AS3645A LED FLASH CONTROLLER DRIVER
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: linux-media@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/i2c/as3645a.c
F: include/media/i2c/as3645a.h
ASAHI KASEI AK8974 DRIVER
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-iio@vger.kernel.org
@ -3575,7 +3558,7 @@ F: drivers/media/platform/coda/
COMMON CLK FRAMEWORK
M: Michael Turquette <mturquette@baylibre.com>
M: Stephen Boyd <sboyd@codeaurora.org>
M: Stephen Boyd <sboyd@kernel.org>
L: linux-clk@vger.kernel.org
Q: http://patchwork.kernel.org/project/linux-clk/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
@ -6009,6 +5992,12 @@ L: linux-input@vger.kernel.org
S: Maintained
F: drivers/input/touchscreen/goodix.c
GPD POCKET FAN DRIVER
M: Hans de Goede <hdegoede@redhat.com>
L: platform-driver-x86@vger.kernel.org
S: Maintained
F: drivers/platform/x86/gpd-pocket-fan.c
GPIO ACPI SUPPORT
M: Mika Westerberg <mika.westerberg@linux.intel.com>
M: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
@ -6946,7 +6935,7 @@ INFINIBAND SUBSYSTEM
M: Doug Ledford <dledford@redhat.com>
M: Jason Gunthorpe <jgg@mellanox.com>
L: linux-rdma@vger.kernel.org
W: http://www.openfabrics.org/
W: https://github.com/linux-rdma/rdma-core
Q: http://patchwork.kernel.org/project/linux-rdma/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
S: Supported
@ -7136,6 +7125,14 @@ R: Dan Williams <dan.j.williams@intel.com>
S: Odd fixes
F: drivers/dma/iop-adma.c
INTEL IPU3 CSI-2 CIO2 DRIVER
M: Yong Zhi <yong.zhi@intel.com>
M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
S: Maintained
F: drivers/media/pci/intel/ipu3/
F: Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst
INTEL IXP4XX QMGR, NPE, ETHERNET and HSS SUPPORT
M: Krzysztof Halasa <khalasa@piap.pl>
S: Maintained
@ -8749,6 +8746,15 @@ T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/dvb-frontends/stv6111*
MEDIA DRIVERS FOR NVIDIA TEGRA - VDE
M: Dmitry Osipenko <digetx@gmail.com>
L: linux-media@vger.kernel.org
L: linux-tegra@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
F: Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
F: drivers/staging/media/tegra-vde/
MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
M: Mauro Carvalho Chehab <mchehab@kernel.org>
@ -8930,12 +8936,13 @@ W: http://www.mellanox.com
Q: http://patchwork.ozlabs.org/project/netdev/list/
F: drivers/net/ethernet/mellanox/mlxfw/
MELLANOX MLX CPLD HOTPLUG DRIVER
MELLANOX HARDWARE PLATFORM SUPPORT
M: Andy Shevchenko <andy@infradead.org>
M: Darren Hart <dvhart@infradead.org>
M: Vadim Pasternak <vadimp@mellanox.com>
L: platform-driver-x86@vger.kernel.org
S: Supported
F: drivers/platform/x86/mlxcpld-hotplug.c
F: include/linux/platform_data/mlxcpld-hotplug.h
F: drivers/platform/mellanox/
MELLANOX MLX4 core VPI driver
M: Tariq Toukan <tariqt@mellanox.com>
@ -9009,6 +9016,7 @@ L: linux-kernel@vger.kernel.org
S: Supported
F: kernel/sched/membarrier.c
F: include/uapi/linux/membarrier.h
F: arch/powerpc/include/asm/membarrier.h
MEMORY MANAGEMENT
L: linux-mm@kvack.org
@ -9180,6 +9188,7 @@ S: Supported
F: Documentation/devicetree/bindings/mips/
F: Documentation/mips/
F: arch/mips/
F: drivers/platform/mips/
MIPS BOSTON DEVELOPMENT BOARD
M: Paul Burton <paul.burton@mips.com>
@ -9207,6 +9216,25 @@ F: arch/mips/include/asm/mach-loongson32/
F: drivers/*/*loongson1*
F: drivers/*/*/*loongson1*
MIPS/LOONGSON2 ARCHITECTURE
M: Jiaxun Yang <jiaxun.yang@flygoat.com>
L: linux-mips@linux-mips.org
S: Maintained
F: arch/mips/loongson64/*{2e/2f}*
F: arch/mips/include/asm/mach-loongson64/
F: drivers/*/*loongson2*
F: drivers/*/*/*loongson2*
MIPS/LOONGSON3 ARCHITECTURE
M: Huacai Chen <chenhc@lemote.com>
L: linux-mips@linux-mips.org
S: Maintained
F: arch/mips/loongson64/
F: arch/mips/include/asm/mach-loongson64/
F: drivers/platform/mips/cpu_hwmon.c
F: drivers/*/*loongson3*
F: drivers/*/*/*loongson3*
MIPS RINT INSTRUCTION EMULATION
M: Aleksandar Markovic <aleksandar.markovic@mips.com>
L: linux-mips@linux-mips.org
@ -9252,7 +9280,6 @@ F: drivers/media/dvb-frontends/mn88473*
MODULE SUPPORT
M: Jessica Yu <jeyu@kernel.org>
M: Rusty Russell <rusty@rustcorp.com.au>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git modules-next
S: Maintained
F: include/linux/module.h
@ -10165,6 +10192,14 @@ S: Maintained
F: drivers/media/i2c/ov7670.c
F: Documentation/devicetree/bindings/media/i2c/ov7670.txt
OMNIVISION OV7740 SENSOR DRIVER
M: Wenyou Yang <wenyou.yang@microchip.com>
L: linux-media@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/i2c/ov7740.c
F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
ONENAND FLASH DRIVER
M: Kyungmin Park <kyungmin.park@samsung.com>
L: linux-mtd@lists.infradead.org
@ -10259,7 +10294,7 @@ F: include/uapi/linux/openvswitch.h
OPERATING PERFORMANCE POINTS (OPP)
M: Viresh Kumar <vireshk@kernel.org>
M: Nishanth Menon <nm@ti.com>
M: Stephen Boyd <sboyd@codeaurora.org>
M: Stephen Boyd <sboyd@kernel.org>
L: linux-pm@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git
@ -10394,7 +10429,6 @@ F: Documentation/parport*.txt
PARAVIRT_OPS INTERFACE
M: Juergen Gross <jgross@suse.com>
M: Alok Kataria <akataria@vmware.com>
M: Rusty Russell <rusty@rustcorp.com.au>
L: virtualization@lists.linux-foundation.org
S: Supported
F: Documentation/virtual/paravirt_ops.txt
@ -10513,6 +10547,13 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/pci-armada8k.txt
F: drivers/pci/dwc/pcie-armada8k.c
PCI DRIVER FOR CADENCE PCIE IP
M: Alan Douglas <adouglas@cadence.com>
L: linux-pci@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/pci/cdns,*.txt
F: drivers/pci/cadence/pcie-cadence*
PCI DRIVER FOR FREESCALE LAYERSCAPE
M: Minghuan Lian <minghuan.Lian@freescale.com>
M: Mingkai Hu <mingkai.hu@freescale.com>
@ -10663,8 +10704,12 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
S: Supported
F: Documentation/devicetree/bindings/pci/
F: Documentation/PCI/
F: drivers/acpi/pci*
F: drivers/pci/
F: include/asm-generic/pci*
F: include/linux/pci*
F: include/uapi/linux/pci*
F: lib/pci*
F: arch/x86/pci/
F: arch/x86/kernel/quirks.c
@ -11559,6 +11604,13 @@ S: Maintained
F: Documentation/blockdev/ramdisk.txt
F: drivers/block/brd.c
RANCHU VIRTUAL BOARD FOR MIPS
M: Miodrag Dinic <miodrag.dinic@mips.com>
L: linux-mips@linux-mips.org
S: Supported
F: arch/mips/generic/board-ranchu.c
F: arch/mips/configs/generic/board-ranchu.config
RANDOM NUMBER DRIVER
M: "Theodore Ts'o" <tytso@mit.edu>
S: Maintained
@ -12460,6 +12512,14 @@ T: git git://linuxtv.org/anttip/media_tree.git
S: Maintained
F: drivers/media/tuners/si2157*
SI2165 MEDIA DRIVER
M: Matthias Schwarzott <zzam@gentoo.org>
L: linux-media@vger.kernel.org
W: https://linuxtv.org
Q: http://patchwork.linuxtv.org/project/linux-media/list/
S: Maintained
F: drivers/media/dvb-frontends/si2165*
SI2168 MEDIA DRIVER
M: Antti Palosaari <crope@iki.fi>
L: linux-media@vger.kernel.org
@ -12976,7 +13036,7 @@ F: Documentation/networking/spider_net.txt
F: drivers/net/ethernet/toshiba/spider_net*
SPMI SUBSYSTEM
R: Stephen Boyd <sboyd@codeaurora.org>
R: Stephen Boyd <sboyd@kernel.org>
L: linux-arm-msm@vger.kernel.org
F: Documentation/devicetree/bindings/spmi/
F: drivers/spmi/
@ -13037,12 +13097,6 @@ S: Odd Fixes
F: Documentation/devicetree/bindings/staging/iio/
F: drivers/staging/iio/
STAGING - LIRC (LINUX INFRARED REMOTE CONTROL) DRIVERS
M: Jarod Wilson <jarod@wilsonet.com>
W: http://www.lirc.org/
S: Odd Fixes
F: drivers/staging/media/lirc/
STAGING - LUSTRE PARALLEL FILESYSTEM
M: Oleg Drokin <oleg.drokin@intel.com>
M: Andreas Dilger <andreas.dilger@intel.com>
@ -13289,7 +13343,6 @@ F: include/linux/platform_data/dma-dw.h
F: drivers/dma/dw/
SYNOPSYS DESIGNWARE ENTERPRISE ETHERNET DRIVER
M: Jie Deng <jiedeng@synopsys.com>
M: Jose Abreu <Jose.Abreu@synopsys.com>
L: netdev@vger.kernel.org
S: Supported
@ -13429,6 +13482,15 @@ T: git git://linuxtv.org/anttip/media_tree.git
S: Maintained
F: drivers/media/tuners/tda18218*
TDA18250 MEDIA DRIVER
M: Olli Salonen <olli.salonen@iki.fi>
L: linux-media@vger.kernel.org
W: https://linuxtv.org
Q: http://patchwork.linuxtv.org/project/linux-media/list/
T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/tuners/tda18250*
TDA18271 MEDIA DRIVER
M: Michael Krufky <mkrufky@linuxtv.org>
L: linux-media@vger.kernel.org
@ -13859,7 +13921,7 @@ F: include/linux/usb/tilegx.h
TIMEKEEPING, CLOCKSOURCE CORE, NTP, ALARMTIMER
M: John Stultz <john.stultz@linaro.org>
M: Thomas Gleixner <tglx@linutronix.de>
R: Stephen Boyd <sboyd@codeaurora.org>
R: Stephen Boyd <sboyd@kernel.org>
L: linux-kernel@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
S: Supported
@ -14927,8 +14989,8 @@ S: Maintained
F: drivers/input/tablet/wacom_serial4.c
WATCHDOG DEVICE DRIVERS
M: Wim Van Sebroeck <wim@iguana.be>
R: Guenter Roeck <linux@roeck-us.net>
M: Wim Van Sebroeck <wim@linux-watchdog.org>
M: Guenter Roeck <linux@roeck-us.net>
L: linux-watchdog@vger.kernel.org
W: http://www.linux-watchdog.org/
T: git git://www.linux-watchdog.org/linux-watchdog.git
@ -15095,7 +15157,7 @@ X86 PLATFORM DRIVERS
M: Darren Hart <dvhart@infradead.org>
M: Andy Shevchenko <andy@infradead.org>
L: platform-driver-x86@vger.kernel.org
T: git git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git
T: git git://git.infradead.org/linux-platform-drivers-x86.git
S: Maintained
F: drivers/platform/x86/
F: drivers/platform/olpc/

54
Makefile
View file

@ -434,7 +434,8 @@ export MAKE LEX YACC AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_KASAN CFLAGS_UBSAN
export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE CFLAGS_UBSAN
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
@ -679,6 +680,10 @@ endif
# This selects the stack protector compiler flag. Testing it is delayed
# until after .config has been reprocessed, in the prepare-compiler-check
# target.
ifdef CONFIG_CC_STACKPROTECTOR_AUTO
stackp-flag := $(call cc-option,-fstack-protector-strong,$(call cc-option,-fstack-protector))
stackp-name := AUTO
else
ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
stackp-flag := -fstack-protector
stackp-name := REGULAR
@ -687,16 +692,40 @@ ifdef CONFIG_CC_STACKPROTECTOR_STRONG
stackp-flag := -fstack-protector-strong
stackp-name := STRONG
else
# If either there is no stack protector for this architecture or
# CONFIG_CC_STACKPROTECTOR_NONE is selected, we're done, and $(stackp-name)
# is empty, skipping all remaining stack protector tests.
#
# Force off for distro compilers that enable stack protector by default.
stackp-flag := $(call cc-option, -fno-stack-protector)
KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
endif
endif
endif
# Find arch-specific stack protector compiler sanity-checking script.
ifdef CONFIG_CC_STACKPROTECTOR
ifdef stackp-name
ifneq ($(stackp-flag),)
stackp-path := $(srctree)/scripts/gcc-$(SRCARCH)_$(BITS)-has-stack-protector.sh
stackp-check := $(wildcard $(stackp-path))
# If the wildcard test matches a test script, run it to check functionality.
ifdef stackp-check
ifneq ($(shell $(CONFIG_SHELL) $(stackp-check) $(CC) $(KBUILD_CPPFLAGS) $(biarch)),y)
stackp-broken := y
endif
endif
ifndef stackp-broken
# If the stack protector is functional, enable code that depends on it.
KBUILD_CPPFLAGS += -DCONFIG_CC_STACKPROTECTOR
# Either we've already detected the flag (for AUTO) or we'll fail the
# build in the prepare-compiler-check rule (for specific flag).
KBUILD_CFLAGS += $(stackp-flag)
else
# We have to make sure stack protector is unconditionally disabled if
# the compiler is broken (in case we're going to continue the build in
# AUTO mode).
KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
endif
endif
endif
KBUILD_CFLAGS += $(stackp-flag)
ifeq ($(cc-name),clang)
KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
@ -1091,14 +1120,25 @@ PHONY += prepare-compiler-check
prepare-compiler-check: FORCE
# Make sure compiler supports requested stack protector flag.
ifdef stackp-name
# Warn about CONFIG_CC_STACKPROTECTOR_AUTO having found no option.
ifeq ($(stackp-flag),)
@echo CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
Compiler does not support any known stack-protector >&2
else
# Fail if specifically requested stack protector is missing.
ifeq ($(call cc-option, $(stackp-flag)),)
@echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
$(stackp-flag) not supported by compiler >&2 && exit 1
endif
endif
endif
# Make sure compiler does not have buggy stack-protector support.
ifdef stackp-check
ifneq ($(shell $(CONFIG_SHELL) $(stackp-check) $(CC) $(KBUILD_CPPFLAGS) $(biarch)),y)
# Make sure compiler does not have buggy stack-protector support. If a
# specific stack-protector was requested, fail the build, otherwise warn.
ifdef stackp-broken
ifeq ($(stackp-name),AUTO)
@echo CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
$(stackp-flag) available but compiler is broken: disabling >&2
else
@echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
$(stackp-flag) available but compiler is broken >&2 && exit 1
endif

16
arch/Kconfig
View file

@ -538,16 +538,10 @@ config HAVE_CC_STACKPROTECTOR
- its compiler supports the -fstack-protector option
- it has implemented a stack canary (e.g. __stack_chk_guard)
config CC_STACKPROTECTOR
def_bool n
help
Set when a stack-protector mode is enabled, so that the build
can enable kernel-side support for the GCC feature.
choice
prompt "Stack Protector buffer overflow detection"
depends on HAVE_CC_STACKPROTECTOR
default CC_STACKPROTECTOR_NONE
default CC_STACKPROTECTOR_AUTO
help
This option turns on the "stack-protector" GCC feature. This
feature puts, at the beginning of functions, a canary value on
@ -564,7 +558,6 @@ config CC_STACKPROTECTOR_NONE
config CC_STACKPROTECTOR_REGULAR
bool "Regular"
select CC_STACKPROTECTOR
help
Functions will have the stack-protector canary logic added if they
have an 8-byte or larger character array on the stack.
@ -578,7 +571,6 @@ config CC_STACKPROTECTOR_REGULAR
config CC_STACKPROTECTOR_STRONG
bool "Strong"
select CC_STACKPROTECTOR
help
Functions will have the stack-protector canary logic added in any
of the following conditions:
@ -596,6 +588,12 @@ config CC_STACKPROTECTOR_STRONG
about 20% of all kernel functions, which increases the kernel code
size by about 2%.
config CC_STACKPROTECTOR_AUTO
bool "Automatic"
help
If the compiler supports it, the best available stack-protector
option will be chosen.
endchoice
config THIN_ARCHIVES

1
arch/alpha/kernel/console.c
View file

@ -21,6 +21,7 @@
struct pci_controller *pci_vga_hose;
static struct resource alpha_vga = {
.name = "alpha-vga+",
.flags = IORESOURCE_IO,
.start = 0x3C0,
.end = 0x3DF
};

2
arch/arm/boot/dts/omap3-n900.dts
View file

@ -780,6 +780,8 @@
reset-gpio = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102 */
lens-focus = <&ad5820>;
port {
csi_cam1: endpoint {
bus-type = <3>; /* CCP2 */

1
arch/arm/include/asm/bitops.h
View file

@ -338,6 +338,7 @@ static inline int find_next_bit_le(const void *p, int size, int offset)
#endif
#include <asm-generic/bitops/find.h>
#include <asm-generic/bitops/le.h>
/*

5
arch/arm/include/asm/pci.h
View file

@ -10,10 +10,7 @@ extern unsigned long pcibios_min_io;
extern unsigned long pcibios_min_mem;
#define PCIBIOS_MIN_MEM pcibios_min_mem
static inline int pcibios_assign_all_busses(void)
{
return pci_has_flag(PCI_REASSIGN_ALL_RSRC);
}
#define pcibios_assign_all_busses() pci_has_flag(PCI_REASSIGN_ALL_BUS)
#ifdef CONFIG_PCI_DOMAINS
static inline int pci_proc_domain(struct pci_bus *bus)

2
arch/arm/kernel/bios32.c
View file

@ -527,7 +527,7 @@ void pci_common_init_dev(struct device *parent, struct hw_pci *hw)
struct pci_sys_data *sys;
LIST_HEAD(head);
pci_add_flags(PCI_REASSIGN_ALL_RSRC);
pci_add_flags(PCI_REASSIGN_ALL_BUS);
if (hw->preinit)
hw->preinit();
pcibios_init_hw(parent, hw, &head);

1
arch/arm/mach-mvebu/Kconfig
View file

@ -10,7 +10,6 @@ menuconfig ARCH_MVEBU
select ZONE_DMA if ARM_LPAE
select GPIOLIB
select PCI_QUIRKS if PCI
select OF_ADDRESS_PCI
if ARCH_MVEBU

1
arch/arm64/Kconfig
View file

@ -16,6 +16,7 @@ config ARM64
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
select ARCH_HAS_KCOV
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_SG_CHAIN
select ARCH_HAS_STRICT_KERNEL_RWX

17
arch/arm64/include/asm/kasan.h
View file

@ -12,7 +12,8 @@
/*
* KASAN_SHADOW_START: beginning of the kernel virtual addresses.
* KASAN_SHADOW_END: KASAN_SHADOW_START + 1/8 of kernel virtual addresses.
* KASAN_SHADOW_END: KASAN_SHADOW_START + 1/N of kernel virtual addresses,
* where N = (1 << KASAN_SHADOW_SCALE_SHIFT).
*/
#define KASAN_SHADOW_START (VA_START)
#define KASAN_SHADOW_END (KASAN_SHADOW_START + KASAN_SHADOW_SIZE)
@ -20,14 +21,16 @@
/*
* This value is used to map an address to the corresponding shadow
* address by the following formula:
* shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET;
* shadow_addr = (address >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET
*
* (1 << 61) shadow addresses - [KASAN_SHADOW_OFFSET,KASAN_SHADOW_END]
* cover all 64-bits of virtual addresses. So KASAN_SHADOW_OFFSET
* should satisfy the following equation:
* KASAN_SHADOW_OFFSET = KASAN_SHADOW_END - (1ULL << 61)
* (1 << (64 - KASAN_SHADOW_SCALE_SHIFT)) shadow addresses that lie in range
* [KASAN_SHADOW_OFFSET, KASAN_SHADOW_END) cover all 64-bits of virtual
* addresses. So KASAN_SHADOW_OFFSET should satisfy the following equation:
* KASAN_SHADOW_OFFSET = KASAN_SHADOW_END -
* (1ULL << (64 - KASAN_SHADOW_SCALE_SHIFT))
*/
#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << (64 - 3)))
#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << \
(64 - KASAN_SHADOW_SCALE_SHIFT)))
void kasan_init(void);
void kasan_copy_shadow(pgd_t *pgdir);

3
arch/arm64/include/asm/memory.h
View file

@ -85,7 +85,8 @@
* stack size when KASAN is in use.
*/
#ifdef CONFIG_KASAN
#define KASAN_SHADOW_SIZE (UL(1) << (VA_BITS - 3))
#define KASAN_SHADOW_SCALE_SHIFT 3
#define KASAN_SHADOW_SIZE (UL(1) << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
#define KASAN_THREAD_SHIFT 1
#else
#define KASAN_SHADOW_SIZE (0)

4
arch/arm64/kernel/entry.S
View file

@ -324,6 +324,10 @@ alternative_else_nop_endif
ldp x28, x29, [sp, #16 * 14]
ldr lr, [sp, #S_LR]
add sp, sp, #S_FRAME_SIZE // restore sp
/*
* ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
* when returning from IPI handler, and when returning to user-space.
*/
.if \el == 0
alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0

5
arch/arm64/kernel/perf_event.c
View file

@ -925,9 +925,8 @@ static void __armv8pmu_probe_pmu(void *info)
pmceid[0] = read_sysreg(pmceid0_el0);
pmceid[1] = read_sysreg(pmceid1_el0);
bitmap_from_u32array(cpu_pmu->pmceid_bitmap,
ARMV8_PMUV3_MAX_COMMON_EVENTS, pmceid,
ARRAY_SIZE(pmceid));
bitmap_from_arr32(cpu_pmu->pmceid_bitmap,
pmceid, ARMV8_PMUV3_MAX_COMMON_EVENTS);
}
static int armv8pmu_probe_pmu(struct arm_pmu *cpu_pmu)

3
arch/arm64/mm/kasan_init.c
View file

@ -135,7 +135,8 @@ static void __init kasan_pgd_populate(unsigned long addr, unsigned long end,
/* The early shadow maps everything to a single page of zeroes */
asmlinkage void __init kasan_early_init(void)
{
BUILD_BUG_ON(KASAN_SHADOW_OFFSET != KASAN_SHADOW_END - (1UL << 61));
BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=
KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT)));
BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_START, PGDIR_SIZE));
BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE));
kasan_pgd_populate(KASAN_SHADOW_START, KASAN_SHADOW_END, NUMA_NO_NODE,

9
arch/arm64/mm/mmu.c
View file

@ -685,12 +685,14 @@ int kern_addr_valid(unsigned long addr)
}
#ifdef CONFIG_SPARSEMEM_VMEMMAP
#if !ARM64_SWAPPER_USES_SECTION_MAPS
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node)
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
struct vmem_altmap *altmap)
{
return vmemmap_populate_basepages(start, end, node);
}
#else /* !ARM64_SWAPPER_USES_SECTION_MAPS */
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node)
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
struct vmem_altmap *altmap)
{
unsigned long addr = start;
unsigned long next;
@ -725,7 +727,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node)
return 0;
}
#endif /* CONFIG_ARM64_64K_PAGES */
void vmemmap_free(unsigned long start, unsigned long end)
void vmemmap_free(unsigned long start, unsigned long end,
struct vmem_altmap *altmap)
{
}
#endif /* CONFIG_SPARSEMEM_VMEMMAP */

13
arch/ia64/kernel/perfmon.c
View file

@ -2610,17 +2610,10 @@ pfm_get_task(pfm_context_t *ctx, pid_t pid, struct task_struct **task)
if (pid < 2) return -EPERM;
if (pid != task_pid_vnr(current)) {
read_lock(&tasklist_lock);
p = find_task_by_vpid(pid);
/* make sure task cannot go away while we operate on it */
if (p) get_task_struct(p);
read_unlock(&tasklist_lock);
if (p == NULL) return -ESRCH;
p = find_get_task_by_vpid(pid);
if (!p)
return -ESRCH;
}
ret = pfm_task_incompatible(ctx, p);

6
arch/ia64/mm/discontig.c
View file

@ -754,12 +754,14 @@ void arch_refresh_nodedata(int update_node, pg_data_t *update_pgdat)
#endif
#ifdef CONFIG_SPARSEMEM_VMEMMAP
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node)
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
struct vmem_altmap *altmap)
{
return vmemmap_populate_basepages(start, end, node);
}
void vmemmap_free(unsigned long start, unsigned long end)
void vmemmap_free(unsigned long start, unsigned long end,
struct vmem_altmap *altmap)
{
}
#endif

18
arch/ia64/mm/init.c
View file

@ -501,7 +501,7 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
if (map_start < map_end)
memmap_init_zone((unsigned long)(map_end - map_start),
args->nid, args->zone, page_to_pfn(map_start),
MEMMAP_EARLY);
MEMMAP_EARLY, NULL);
return 0;
}
@ -509,9 +509,10 @@ void __meminit
memmap_init (unsigned long size, int nid, unsigned long zone,
unsigned long start_pfn)
{
if (!vmem_map)
memmap_init_zone(size, nid, zone, start_pfn, MEMMAP_EARLY);
else {
if (!vmem_map) {
memmap_init_zone(size, nid, zone, start_pfn, MEMMAP_EARLY,
NULL);
} else {
struct page *start;
struct memmap_init_callback_data args;
@ -647,13 +648,14 @@ mem_init (void)
}
#ifdef CONFIG_MEMORY_HOTPLUG
int arch_add_memory(int nid, u64 start, u64 size, bool want_memblock)
int arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
bool want_memblock)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
ret = __add_pages(nid, start_pfn, nr_pages, want_memblock);
ret = __add_pages(nid, start_pfn, nr_pages, altmap, want_memblock);
if (ret)
printk("%s: Problem encountered in __add_pages() as ret=%d\n",
__func__, ret);
@ -662,7 +664,7 @@ int arch_add_memory(int nid, u64 start, u64 size, bool want_memblock)
}
#ifdef CONFIG_MEMORY_HOTREMOVE
int arch_remove_memory(u64 start, u64 size)
int arch_remove_memory(u64 start, u64 size, struct vmem_altmap *altmap)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
@ -670,7 +672,7 @@ int arch_remove_memory(u64 start, u64 size)
int ret;
zone = page_zone(pfn_to_page(start_pfn));
ret = __remove_pages(zone, start_pfn, nr_pages);
ret = __remove_pages(zone, start_pfn, nr_pages, altmap);
if (ret)
pr_warn("%s: Problem encountered in __remove_pages() as"
" ret=%d\n", __func__, ret);

3
arch/m68k/include/asm/bitops.h
View file

@ -311,7 +311,6 @@ static inline int bfchg_mem_test_and_change_bit(int nr,
* functions.
*/
#if defined(CONFIG_CPU_HAS_NO_BITFIELDS)
#include <asm-generic/bitops/find.h>
#include <asm-generic/bitops/ffz.h>
#else
@ -441,6 +440,8 @@ static inline unsigned long ffz(unsigned long word)
#endif
#include <asm-generic/bitops/find.h>
#ifdef __KERNEL__
#if defined(CONFIG_CPU_HAS_NO_BITFIELDS)

23
arch/mips/Kconfig
View file

@ -7,8 +7,6 @@ config MIPS
select ARCH_DISCARD_MEMBLOCK
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select ARCH_SUPPORTS_UPROBES
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
@ -119,12 +117,12 @@ config MIPS_GENERIC
select SYS_SUPPORTS_MULTITHREADING
select SYS_SUPPORTS_RELOCATABLE
select SYS_SUPPORTS_SMARTMIPS
select USB_EHCI_BIG_ENDIAN_DESC if BIG_ENDIAN
select USB_EHCI_BIG_ENDIAN_MMIO if BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_DESC if BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_MMIO if BIG_ENDIAN
select USB_UHCI_BIG_ENDIAN_DESC if BIG_ENDIAN
select USB_UHCI_BIG_ENDIAN_MMIO if BIG_ENDIAN
select USB_EHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_EHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_UHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_UHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USE_OF
help
Select this to build a kernel which aims to support multiple boards,
@ -253,6 +251,7 @@ config BCM47XX
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_MIPS16
select SYS_SUPPORTS_ZBOOT
select SYS_HAS_EARLY_PRINTK
select USE_GENERIC_EARLY_PRINTK_8250
select GPIOLIB
@ -341,6 +340,8 @@ config MACH_DECSTATION
config MACH_JAZZ
bool "Jazz family of machines"
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select FW_ARC
select FW_ARC32
select ARCH_MAY_HAVE_PC_FDC
@ -476,6 +477,8 @@ config MACH_PISTACHIO
config MIPS_MALTA
bool "MIPS Malta board"
select ARCH_MAY_HAVE_PC_FDC
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select BOOT_ELF32
select BOOT_RAW
select BUILTIN_DTB
@ -613,6 +616,7 @@ config SGI_IP22
bool "SGI IP22 (Indy/Indigo2)"
select FW_ARC
select FW_ARC32
select ARCH_MIGHT_HAVE_PC_SERIO
select BOOT_ELF32
select CEVT_R4K
select CSRC_R4K
@ -675,6 +679,7 @@ config SGI_IP28
bool "SGI IP28 (Indigo2 R10k)"
select FW_ARC
select FW_ARC64
select ARCH_MIGHT_HAVE_PC_SERIO
select BOOT_ELF64
select CEVT_R4K
select CSRC_R4K
@ -824,6 +829,8 @@ config SNI_RM
select FW_ARC32 if CPU_LITTLE_ENDIAN
select FW_SNIPROM if CPU_BIG_ENDIAN
select ARCH_MAY_HAVE_PC_FDC
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select BOOT_ELF32
select CEVT_R4K
select CSRC_R4K

8
arch/mips/Makefile
View file

@ -216,6 +216,12 @@ cflags-$(toolchain-msa) += -DTOOLCHAIN_SUPPORTS_MSA
endif
toolchain-virt := $(call cc-option-yn,$(mips-cflags) -mvirt)
cflags-$(toolchain-virt) += -DTOOLCHAIN_SUPPORTS_VIRT
# For -mmicromips, use -Wa,-fatal-warnings to catch unsupported -mxpa which
# only warns
xpa-cflags-y := $(mips-cflags)
xpa-cflags-$(micromips-ase) += -mmicromips -Wa$(comma)-fatal-warnings
toolchain-xpa := $(call cc-option-yn,$(xpa-cflags-y) -mxpa)
cflags-$(toolchain-xpa) += -DTOOLCHAIN_SUPPORTS_XPA
#
# Firmware support
@ -228,7 +234,7 @@ libs-y += arch/mips/fw/lib/
#
# Kernel compression
#
ifdef SYS_SUPPORTS_ZBOOT
ifdef CONFIG_SYS_SUPPORTS_ZBOOT
COMPRESSION_FNAME = vmlinuz
else
COMPRESSION_FNAME = vmlinux

1
arch/mips/bcm47xx/Platform
View file

@ -5,3 +5,4 @@ platform-$(CONFIG_BCM47XX) += bcm47xx/
cflags-$(CONFIG_BCM47XX) += \
-I$(srctree)/arch/mips/include/asm/mach-bcm47xx
load-$(CONFIG_BCM47XX) := 0xffffffff80001000
zload-$(CONFIG_BCM47XX) += 0xffffffff80400000

6
arch/mips/boot/compressed/Makefile
View file

@ -133,4 +133,8 @@ vmlinuz.srec: vmlinuz
uzImage.bin: vmlinuz.bin FORCE
$(call if_changed,uimage,none)
clean-files := $(objtree)/vmlinuz $(objtree)/vmlinuz.{32,ecoff,bin,srec}
clean-files += $(objtree)/vmlinuz
clean-files += $(objtree)/vmlinuz.32
clean-files += $(objtree)/vmlinuz.ecoff
clean-files += $(objtree)/vmlinuz.bin
clean-files += $(objtree)/vmlinuz.srec

1
arch/mips/boot/dts/ingenic/Makefile
View file

@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_JZ4740_QI_LB60) += qi_lb60.dtb
dtb-$(CONFIG_JZ4770_GCW0) += gcw0.dtb
dtb-$(CONFIG_JZ4780_CI20) += ci20.dtb
obj-y += $(patsubst %.dtb, %.dtb.o, $(dtb-y))

62
arch/mips/boot/dts/ingenic/gcw0.dts Normal file
View file

@ -0,0 +1,62 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
#include "jz4770.dtsi"
/ {
compatible = "gcw,zero", "ingenic,jz4770";
model = "GCW Zero";
aliases {
serial0 = &uart0;
serial1 = &uart1;
serial2 = &uart2;
serial3 = &uart3;
};
chosen {
stdout-path = "serial2:57600n8";
};
board {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
otg_phy: otg-phy {
compatible = "usb-nop-xceiv";
clocks = <&cgu JZ4770_CLK_OTG_PHY>;
clock-names = "main_clk";
};
};
};
&ext {
clock-frequency = <12000000>;
};
&uart2 {
status = "okay";
};
&cgu {
/* Put high-speed peripherals under PLL1, such that we can change the
* PLL0 frequency on demand without having to suspend peripherals.
* We use a rate of 432 MHz, which is the least common multiple of
* 27 MHz (required by TV encoder) and 48 MHz (required by USB host).
*/
assigned-clocks =
<&cgu JZ4770_CLK_PLL1>,
<&cgu JZ4770_CLK_UHC>;
assigned-clock-parents =
<0>,
<&cgu JZ4770_CLK_PLL1>;
assigned-clock-rates =
<432000000>;
};
&uhc {
/* The WiFi module is connected to the UHC. */
status = "okay";
};

212
arch/mips/boot/dts/ingenic/jz4770.dtsi Normal file
View file

@ -0,0 +1,212 @@
// SPDX-License-Identifier: GPL-2.0
#include <dt-bindings/clock/jz4770-cgu.h>
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "ingenic,jz4770";
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
interrupt-controller;
compatible = "mti,cpu-interrupt-controller";
};
intc: interrupt-controller@10001000 {
compatible = "ingenic,jz4770-intc";
reg = <0x10001000 0x40>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&cpuintc>;
interrupts = <2>;
};
ext: ext {
compatible = "fixed-clock";
#clock-cells = <0>;
};
osc32k: osc32k {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32768>;
};
cgu: jz4770-cgu@10000000 {
compatible = "ingenic,jz4770-cgu";
reg = <0x10000000 0x100>;
clocks = <&ext>, <&osc32k>;
clock-names = "ext", "osc32k";
#clock-cells = <1>;
};
pinctrl: pin-controller@10010000 {
compatible = "ingenic,jz4770-pinctrl";
reg = <0x10010000 0x600>;
#address-cells = <1>;
#size-cells = <0>;
gpa: gpio@0 {
compatible = "ingenic,jz4770-gpio";
reg = <0>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 32>;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
interrupts = <17>;
};
gpb: gpio@1 {
compatible = "ingenic,jz4770-gpio";
reg = <1>;
gpio-controller;
gpio-ranges = <&pinctrl 0 32 32>;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
interrupts = <16>;
};
gpc: gpio@2 {
compatible = "ingenic,jz4770-gpio";
reg = <2>;
gpio-controller;
gpio-ranges = <&pinctrl 0 64 32>;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
interrupts = <15>;
};
gpd: gpio@3 {
compatible = "ingenic,jz4770-gpio";
reg = <3>;
gpio-controller;
gpio-ranges = <&pinctrl 0 96 32>;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
interrupts = <14>;
};
gpe: gpio@4 {
compatible = "ingenic,jz4770-gpio";
reg = <4>;
gpio-controller;
gpio-ranges = <&pinctrl 0 128 32>;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
interrupts = <13>;
};
gpf: gpio@5 {
compatible = "ingenic,jz4770-gpio";
reg = <5>;
gpio-controller;
gpio-ranges = <&pinctrl 0 160 32>;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
interrupts = <12>;
};
};
uart0: serial@10030000 {
compatible = "ingenic,jz4770-uart";
reg = <0x10030000 0x100>;
clocks = <&ext>, <&cgu JZ4770_CLK_UART0>;
clock-names = "baud", "module";
interrupt-parent = <&intc>;
interrupts = <5>;
status = "disabled";
};
uart1: serial@10031000 {
compatible = "ingenic,jz4770-uart";
reg = <0x10031000 0x100>;
clocks = <&ext>, <&cgu JZ4770_CLK_UART1>;
clock-names = "baud", "module";
interrupt-parent = <&intc>;
interrupts = <4>;
status = "disabled";
};
uart2: serial@10032000 {
compatible = "ingenic,jz4770-uart";
reg = <0x10032000 0x100>;
clocks = <&ext>, <&cgu JZ4770_CLK_UART2>;
clock-names = "baud", "module";
interrupt-parent = <&intc>;
interrupts = <3>;
status = "disabled";
};
uart3: serial@10033000 {
compatible = "ingenic,jz4770-uart";
reg = <0x10033000 0x100>;
clocks = <&ext>, <&cgu JZ4770_CLK_UART3>;
clock-names = "baud", "module";
interrupt-parent = <&intc>;
interrupts = <2>;
status = "disabled";
};
uhc: uhc@13430000 {
compatible = "generic-ohci";
reg = <0x13430000 0x1000>;
clocks = <&cgu JZ4770_CLK_UHC>, <&cgu JZ4770_CLK_UHC_PHY>;
assigned-clocks = <&cgu JZ4770_CLK_UHC>;
assigned-clock-rates = <48000000>;
interrupt-parent = <&intc>;
interrupts = <20>;
status = "disabled";
};
};

1
arch/mips/configs/bigsur_defconfig
View file

@ -153,7 +153,6 @@ CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_INPUT is not set
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_RAW=m
# CONFIG_VT is not set
CONFIG_SERIAL_NONSTANDARD=y

27
arch/mips/configs/gcw0_defconfig Normal file
View file

@ -0,0 +1,27 @@
CONFIG_MACH_INGENIC=y
CONFIG_JZ4770_GCW0=y
CONFIG_HIGHMEM=y
# CONFIG_BOUNCE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_SECCOMP is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_EMBEDDED=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_SUSPEND is not set
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_NETDEVICES=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_INGENIC=y
CONFIG_USB=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PLATFORM=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_TMPFS=y

30
arch/mips/configs/generic/board-ranchu.config Normal file
View file

@ -0,0 +1,30 @@
CONFIG_VIRT_BOARD_RANCHU=y
CONFIG_BATTERY_GOLDFISH=y
CONFIG_FB=y
CONFIG_FB_GOLDFISH=y
CONFIG_GOLDFISH=y
CONFIG_STAGING=y
CONFIG_GOLDFISH_AUDIO=y
CONFIG_GOLDFISH_PIC=y
CONFIG_GOLDFISH_PIPE=y
CONFIG_GOLDFISH_TTY=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_GOLDFISH=y
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_GOLDFISH_EVENTS=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_POWER_SUPPLY=y
CONFIG_POWER_RESET=y
CONFIG_POWER_RESET_SYSCON=y
CONFIG_POWER_RESET_SYSCON_POWEROFF=y
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_VIRTIO_MMIO=y
CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
CONFIG_NETDEVICES=y
CONFIG_VIRTIO_NET=y

1
arch/mips/configs/ip27_defconfig
View file

@ -252,7 +252,6 @@ CONFIG_RT2800PCI=m
CONFIG_WL12XX=m
CONFIG_WL1251=m
# CONFIG_INPUT is not set
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_LIBPS2=m
CONFIG_SERIO_RAW=m
CONFIG_SERIO_ALTERA_PS2=m

1
arch/mips/configs/ip32_defconfig
View file

@ -75,7 +75,6 @@ CONFIG_DE2104X=m
CONFIG_TULIP=m
CONFIG_TULIP_MMIO=y
CONFIG_INPUT_EVDEV=m
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_MACEPS2=y
CONFIG_SERIO_RAW=y
# CONFIG_CONSOLE_TRANSLATIONS is not set

5
arch/mips/configs/malta_defconfig
View file

@ -312,9 +312,8 @@ CONFIG_HOSTAP_PCI=m
CONFIG_IPW2100=m
CONFIG_IPW2100_MONITOR=y
CONFIG_LIBERTAS=m
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO_I8042 is not set
CONFIG_INPUT_MOUSEDEV=y
CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_POWER_RESET=y

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