Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Merge branch 'sched/urgent' into sched/core, to pick up fixes

Browse source 
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar 2018-01-10 10:52:40 +01:00
commit cb1f34ddcc
1628 changed files with 17475 additions and 10603 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
.mailmap
View file

@ -107,6 +107,7 @@ Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
Mark Brown <broonie@sirena.org.uk>
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
Matthieu CASTET <castet.matthieu@free.fr>

1
Documentation/admin-guide/kernel-parameters.rst
View file

@ -109,6 +109,7 @@ parameter is applicable::
IPV6 IPv6 support is enabled.
ISAPNP ISA PnP code is enabled.
ISDN Appropriate ISDN support is enabled.
ISOL CPU Isolation is enabled.
JOY Appropriate joystick support is enabled.
KGDB Kernel debugger support is enabled.
KVM Kernel Virtual Machine support is enabled.

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

@ -328,11 +328,15 @@
not play well with APC CPU idle - disable it if you have
APC and your system crashes randomly.
apic= [APIC,X86-32] Advanced Programmable Interrupt Controller
apic= [APIC,X86] Advanced Programmable Interrupt Controller
Change the output verbosity whilst booting
Format: { quiet (default) | verbose | debug }
Change the amount of debugging information output
when initialising the APIC and IO-APIC components.
For X86-32, this can also be used to specify an APIC
driver name.
Format: apic=driver_name
Examples: apic=bigsmp
apic_extnmi= [APIC,X86] External NMI delivery setting
Format: { bsp (default) | all | none }
@ -1737,7 +1741,7 @@
isapnp= [ISAPNP]
Format: <RDP>,<reset>,<pci_scan>,<verbosity>
isolcpus= [KNL,SMP] Isolate a given set of CPUs from disturbance.
isolcpus= [KNL,SMP,ISOL] Isolate a given set of CPUs from disturbance.
[Deprecated - use cpusets instead]
Format: [flag-list,]<cpu-list>
@ -2662,7 +2666,7 @@
Valid arguments: on, off
Default: on
nohz_full= [KNL,BOOT]
nohz_full= [KNL,BOOT,SMP,ISOL]
The argument is a cpu list, as described above.
In kernels built with CONFIG_NO_HZ_FULL=y, set
the specified list of CPUs whose tick will be stopped
@ -2708,6 +2712,8 @@
steal time is computed, but won't influence scheduler
behaviour
nopti [X86-64] Disable kernel page table isolation
nolapic [X86-32,APIC] Do not enable or use the local APIC.
nolapic_timer [X86-32,APIC] Do not use the local APIC timer.
@ -3282,6 +3288,12 @@
pt. [PARIDE]
See Documentation/blockdev/paride.txt.
pti= [X86_64]
Control user/kernel address space isolation:
on - enable
off - disable
auto - default setting
pty.legacy_count=
[KNL] Number of legacy pty's. Overwrites compiled-in
default number.

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

@ -230,7 +230,7 @@ If supported by your machine this will be exposed by the WMI bus with
a sysfs attribute called "force_power".
For example the intel-wmi-thunderbolt driver exposes this attribute in:
/sys/devices/platform/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/86CCFD48-205E-4A77-9C48-2021CBEDE341/force_power
/sys/bus/wmi/devices/86CCFD48-205E-4A77-9C48-2021CBEDE341/force_power
To force the power to on, write 1 to this attribute file.
To disable force power, write 0 to this attribute file.

1
Documentation/arm64/silicon-errata.txt
View file

@ -75,3 +75,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
| Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |

7
Documentation/cgroup-v2.txt
View file

@ -898,6 +898,13 @@ controller implements weight and absolute bandwidth limit models for
normal scheduling policy and absolute bandwidth allocation model for
realtime scheduling policy.
WARNING: cgroup2 doesn't yet support control of realtime processes and
the cpu controller can only be enabled when all RT processes are in
the root cgroup. Be aware that system management software may already
have placed RT processes into nonroot cgroups during the system boot
process, and these processes may need to be moved to the root cgroup
before the cpu controller can be enabled.
CPU Interface Files
~~~~~~~~~~~~~~~~~~~

2
Documentation/devicetree/bindings/arm/ccn.txt
View file

@ -15,7 +15,7 @@ Required properties:
Example:
ccn@0x2000000000 {
ccn@2000000000 {
compatible = "arm,ccn-504";
reg = <0x20 0x00000000 0 0x1000000>;
interrupts = <0 181 4>;

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

@ -49,7 +49,7 @@ An interrupt consumer on an SoC using crossbar will use:
interrupts = <GIC_SPI request_number interrupt_level>
Example:
device_x@0x4a023000 {
device_x@4a023000 {
/* Crossbar 8 used */
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
...

2
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt
View file

@ -8,7 +8,7 @@ Required properties:
- interrupts : Should contain MC General interrupt.
Example:
memory-controller@0x7000f000 {
memory-controller@7000f000 {
compatible = "nvidia,tegra20-mc";
reg = <0x7000f000 0x024
0x7000f03c 0x3c4>;

2
Documentation/devicetree/bindings/clock/axi-clkgen.txt
View file

@ -17,7 +17,7 @@ Optional properties:
- clock-output-names : From common clock binding.
Example:
clock@0xff000000 {
clock@ff000000 {
compatible = "adi,axi-clkgen";
#clock-cells = <0>;
reg = <0xff000000 0x1000>;

2
Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
View file

@ -23,7 +23,7 @@ Example:
clocks = <&clk_osc>;
};
aux: aux@0x7e215004 {
aux: aux@7e215004 {
compatible = "brcm,bcm2835-aux";
#clock-cells = <1>;
reg = <0x7e215000 0x8>;

2
Documentation/devicetree/bindings/clock/exynos4-clock.txt
View file

@ -24,7 +24,7 @@ tree sources.
Example 1: An example of a clock controller node is listed below.
clock: clock-controller@0x10030000 {
clock: clock-controller@10030000 {
compatible = "samsung,exynos4210-clock";
reg = <0x10030000 0x20000>;
#clock-cells = <1>;

2
Documentation/devicetree/bindings/clock/exynos5250-clock.txt
View file

@ -22,7 +22,7 @@ tree sources.
Example 1: An example of a clock controller node is listed below.
clock: clock-controller@0x10010000 {
clock: clock-controller@10010000 {
compatible = "samsung,exynos5250-clock";
reg = <0x10010000 0x30000>;
#clock-cells = <1>;

2
Documentation/devicetree/bindings/clock/exynos5410-clock.txt
View file

@ -30,7 +30,7 @@ Example 1: An example of a clock controller node is listed below.
#clock-cells = <0>;
};
clock: clock-controller@0x10010000 {
clock: clock-controller@10010000 {
compatible = "samsung,exynos5410-clock";
reg = <0x10010000 0x30000>;
#clock-cells = <1>;

2
Documentation/devicetree/bindings/clock/exynos5420-clock.txt
View file

@ -23,7 +23,7 @@ tree sources.
Example 1: An example of a clock controller node is listed below.
clock: clock-controller@0x10010000 {
clock: clock-controller@10010000 {
compatible = "samsung,exynos5420-clock";
reg = <0x10010000 0x30000>;
#clock-cells = <1>;

2
Documentation/devicetree/bindings/clock/exynos5440-clock.txt
View file

@ -21,7 +21,7 @@ tree sources.
Example: An example of a clock controller node is listed below.
clock: clock-controller@0x10010000 {
clock: clock-controller@10010000 {
compatible = "samsung,exynos5440-clock";
reg = <0x160000 0x10000>;
#clock-cells = <1>;

2
Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt
View file

@ -14,7 +14,7 @@ Required properties:
Example:
pllctrl: pll-controller@0x02310000 {
pllctrl: pll-controller@02310000 {
compatible = "ti,keystone-pllctrl", "syscon";
reg = <0x02310000 0x200>;
};

4
Documentation/devicetree/bindings/clock/zx296702-clk.txt
View file

@ -20,13 +20,13 @@ ID in its "clocks" phandle cell. See include/dt-bindings/clock/zx296702-clock.h
for the full list of zx296702 clock IDs.
topclk: topcrm@0x09800000 {
topclk: topcrm@09800000 {
compatible = "zte,zx296702-topcrm-clk";
reg = <0x09800000 0x1000>;
#clock-cells = <1>;
};
uart0: serial@0x09405000 {
uart0: serial@09405000 {
compatible = "zte,zx296702-uart";
reg = <0x09405000 0x1000>;
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;

4
Documentation/devicetree/bindings/crypto/fsl-sec4.txt
View file

@ -456,7 +456,7 @@ System ON/OFF key driver
Definition: this is phandle to the register map node.
EXAMPLE:
snvs-pwrkey@0x020cc000 {
snvs-pwrkey@020cc000 {
compatible = "fsl,sec-v4.0-pwrkey";
regmap = <&snvs>;
interrupts = <0 4 0x4>
@ -545,7 +545,7 @@ FULL EXAMPLE
interrupts = <93 2>;
};
snvs-pwrkey@0x020cc000 {
snvs-pwrkey@020cc000 {
compatible = "fsl,sec-v4.0-pwrkey";
regmap = <&sec_mon>;
interrupts = <0 4 0x4>;

2
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
View file

@ -9,7 +9,7 @@ Required properties:
- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
Example:
dfi: dfi@0xff630000 {
dfi: dfi@ff630000 {
compatible = "rockchip,rk3399-dfi";
reg = <0x00 0xff630000 0x00 0x4000>;
rockchip,pmu = <&pmugrf>;

4
Documentation/devicetree/bindings/display/atmel,lcdc.txt
View file

@ -27,7 +27,7 @@ Optional properties:
Example:
fb0: fb@0x00500000 {
fb0: fb@00500000 {
compatible = "atmel,at91sam9g45-lcdc";
reg = <0x00500000 0x1000>;
interrupts = <23 3 0>;
@ -41,7 +41,7 @@ Example:
Example for fixed framebuffer memory:
fb0: fb@0x00500000 {
fb0: fb@00500000 {
compatible = "atmel,at91sam9263-lcdc";
reg = <0x00700000 0x1000 0x70000000 0x200000>;
[...]

4
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
View file

@ -73,7 +73,7 @@ Hypervisor OS configuration:
max-read-transactions = <31>;
channel-reset-timeout-cycles = <0x500>;
hidma_24: dma-controller@0x5c050000 {
hidma_24: dma-controller@5c050000 {
compatible = "qcom,hidma-1.0";
reg = <0 0x5c050000 0x0 0x1000>,
<0 0x5c0b0000 0x0 0x1000>;
@ -85,7 +85,7 @@ Hypervisor OS configuration:
Guest OS configuration:
hidma_24: dma-controller@0x5c050000 {
hidma_24: dma-controller@5c050000 {
compatible = "qcom,hidma-1.0";
reg = <0 0x5c050000 0x0 0x1000>,
<0 0x5c0b0000 0x0 0x1000>;

2
Documentation/devicetree/bindings/dma/zxdma.txt
View file

@ -13,7 +13,7 @@ Required properties:
Example:
Controller:
dma: dma-controller@0x09c00000{
dma: dma-controller@09c00000{
compatible = "zte,zx296702-dma";
reg = <0x09c00000 0x1000>;
clocks = <&topclk ZX296702_DMA_ACLK>;

13
Documentation/devicetree/bindings/eeprom/at25.txt
View file

@ -1,7 +1,12 @@
EEPROMs (SPI) compatible with Atmel at25.
Required properties:
- compatible : "atmel,at25".
- compatible : Should be "<vendor>,<type>", and generic value "atmel,at25".
Example "<vendor>,<type>" values:
"microchip,25lc040"
"st,m95m02"
"st,m95256"
- reg : chip select number
- spi-max-frequency : max spi frequency to use
- pagesize : size of the eeprom page
@ -13,7 +18,7 @@ Optional properties:
- spi-cpol : SPI inverse clock polarity, as per spi-bus bindings.
- read-only : this parameter-less property disables writes to the eeprom
Obsolete legacy properties are can be used in place of "size", "pagesize",
Obsolete legacy properties can be used in place of "size", "pagesize",
"address-width", and "read-only":
- at25,byte-len : total eeprom size in bytes
- at25,addr-mode : addr-mode flags, as defined in include/linux/spi/eeprom.h
@ -22,8 +27,8 @@ Obsolete legacy properties are can be used in place of "size", "pagesize",
Additional compatible properties are also allowed.
Example:
at25@0 {
compatible = "atmel,at25", "st,m95256";
eeprom@0 {
compatible = "st,m95256", "atmel,at25";
reg = <0>
spi-max-frequency = <5000000>;
spi-cpha;

2
Documentation/devicetree/bindings/gpio/gpio-altera.txt
View file

@ -30,7 +30,7 @@ Optional properties:
Example:
gpio_altr: gpio@0xff200000 {
gpio_altr: gpio@ff200000 {
compatible = "altr,pio-1.0";
reg = <0xff200000 0x10>;
interrupts = <0 45 4>;

2
Documentation/devicetree/bindings/i2c/i2c-jz4780.txt
View file

@ -18,7 +18,7 @@ Optional properties:
Example
/ {
i2c4: i2c4@0x10054000 {
i2c4: i2c4@10054000 {
compatible = "ingenic,jz4780-i2c";
reg = <0x10054000 0x1000>;

2
Documentation/devicetree/bindings/iio/pressure/hp03.txt
View file

@ -10,7 +10,7 @@ Required properties:
Example:
hp03@0x77 {
hp03@77 {
compatible = "hoperf,hp03";
reg = <0x77>;
xclr-gpio = <&portc 0 0x0>;

2
Documentation/devicetree/bindings/input/touchscreen/bu21013.txt
View file

@ -15,7 +15,7 @@ Optional properties:
Example:
i2c@80110000 {
bu21013_tp@0x5c {
bu21013_tp@5c {
compatible = "rohm,bu21013_tp";
reg = <0x5c>;
touch-gpio = <&gpio2 20 0x4>;

4
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
View file

@ -155,7 +155,7 @@ Example:
<0x0 0xe112f000 0 0x02000>,
<0x0 0xe1140000 0 0x10000>,
<0x0 0xe1160000 0 0x10000>;
v2m0: v2m@0x8000 {
v2m0: v2m@8000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x80000 0 0x1000>;
@ -163,7 +163,7 @@ Example:
....
v2mN: v2m@0x9000 {
v2mN: v2m@9000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x90000 0 0x1000>;

2
Documentation/devicetree/bindings/interrupt-controller/img,meta-intc.txt
View file

@ -71,7 +71,7 @@ Example 2:
* An interrupt generating device that is wired to a Meta external
* trigger block.
*/
uart1: uart@0x02004c00 {
uart1: uart@02004c00 {
// Interrupt source '5' that is level-sensitive.
// Note that there are only two cells as specified in the
// interrupt parent's '#interrupt-cells' property.

2
Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.txt
View file

@ -51,7 +51,7 @@ Example 1:
/*
* TZ1090 PDC block
*/
pdc: pdc@0x02006000 {
pdc: pdc@02006000 {
// This is an interrupt controller node.
interrupt-controller;

2
Documentation/devicetree/bindings/interrupt-controller/st,spear3xx-shirq.txt
View file

@ -39,7 +39,7 @@ Example:
The following is an example from the SPEAr320 SoC dtsi file.
shirq: interrupt-controller@0xb3000000 {
shirq: interrupt-controller@b3000000 {
compatible = "st,spear320-shirq";
reg = <0xb3000000 0x1000>;
interrupts = <28 29 30 1>;

6
Documentation/devicetree/bindings/mailbox/altera-mailbox.txt
View file

@ -14,7 +14,7 @@ Optional properties:
depends on the interrupt controller parent.
Example:
mbox_tx: mailbox@0x100 {
mbox_tx: mailbox@100 {
compatible = "altr,mailbox-1.0";
reg = <0x100 0x8>;
interrupt-parent = < &gic_0 >;
@ -22,7 +22,7 @@ Example:
#mbox-cells = <1>;
};
mbox_rx: mailbox@0x200 {
mbox_rx: mailbox@200 {
compatible = "altr,mailbox-1.0";
reg = <0x200 0x8>;
interrupt-parent = < &gic_0 >;
@ -40,7 +40,7 @@ support only one channel).The equivalent "mbox-names" property value can be
used to give a name to the communication channel to be used by the client user.
Example:
mclient0: mclient0@0x400 {
mclient0: mclient0@400 {
compatible = "client-1.0";
reg = <0x400 0x10>;
mbox-names = "mbox-tx", "mbox-rx";

2
Documentation/devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.txt
View file

@ -15,7 +15,7 @@ Optional properties:
- brcm,use-bcm-hdr: present if a BCM header precedes each frame.
Example:
pdc0: iproc-pdc0@0x612c0000 {
pdc0: iproc-pdc0@612c0000 {
compatible = "brcm,iproc-pdc-mbox";
reg = <0 0x612c0000 0 0x445>; /* PDC FS0 regs */
interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;

2
Documentation/devicetree/bindings/media/exynos5-gsc.txt
View file

@ -17,7 +17,7 @@ Optional properties:
Example:
gsc_0: gsc@0x13e00000 {
gsc_0: gsc@13e00000 {
compatible = "samsung,exynos5250-gsc";
reg = <0x13e00000 0x1000>;
interrupts = <0 85 0>;

2
Documentation/devicetree/bindings/media/mediatek-vcodec.txt
View file

@ -68,7 +68,7 @@ vcodec_dec: vcodec@16000000 {
"vdec_bus_clk_src";
};
vcodec_enc: vcodec@0x18002000 {
vcodec_enc: vcodec@18002000 {
compatible = "mediatek,mt8173-vcodec-enc";
reg = <0 0x18002000 0 0x1000>, /*VENC_SYS*/
<0 0x19002000 0 0x1000>; /*VENC_LT_SYS*/

2
Documentation/devicetree/bindings/media/rcar_vin.txt
View file

@ -44,7 +44,7 @@ Device node example
vin0 = &vin0;
};
vin0: vin@0xe6ef0000 {
vin0: vin@e6ef0000 {
compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
clocks = <&mstp8_clks R8A7790_CLK_VIN0>;
reg = <0 0xe6ef0000 0 0x1000>;

2
Documentation/devicetree/bindings/media/samsung-fimc.txt
View file

@ -138,7 +138,7 @@ Example:
};
/* MIPI CSI-2 bus IF sensor */
s5c73m3: sensor@0x1a {
s5c73m3: sensor@1a {
compatible = "samsung,s5c73m3";
reg = <0x1a>;
vddio-supply = <...>;

2
Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
View file

@ -8,7 +8,7 @@ Bindings, specific for the sh_mobile_ceu_camera.c driver:
Example:
ceu0: ceu@0xfe910000 {
ceu0: ceu@fe910000 {
compatible = "renesas,sh-mobile-ceu";
reg = <0xfe910000 0xa0>;
interrupt-parent = <&intcs>;

10
Documentation/devicetree/bindings/media/video-interfaces.txt
View file

@ -154,7 +154,7 @@ imx074 is linked to ceu0 through the MIPI CSI-2 receiver (csi2). ceu0 has a
'port' node which may indicate that at any time only one of the following data
pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
ceu0: ceu@0xfe910000 {
ceu0: ceu@fe910000 {
compatible = "renesas,sh-mobile-ceu";
reg = <0xfe910000 0xa0>;
interrupts = <0x880>;
@ -193,9 +193,9 @@ pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
};
};
i2c0: i2c@0xfff20000 {
i2c0: i2c@fff20000 {
...
ov772x_1: camera@0x21 {
ov772x_1: camera@21 {
compatible = "ovti,ov772x";
reg = <0x21>;
vddio-supply = <&regulator1>;
@ -219,7 +219,7 @@ pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
};
};
imx074: camera@0x1a {
imx074: camera@1a {
compatible = "sony,imx074";
reg = <0x1a>;
vddio-supply = <&regulator1>;
@ -239,7 +239,7 @@ pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
};
};
csi2: csi2@0xffc90000 {
csi2: csi2@ffc90000 {
compatible = "renesas,sh-mobile-csi2";
reg = <0xffc90000 0x1000>;
interrupts = <0x17a0>;

2
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
View file

@ -46,7 +46,7 @@ Optional properties:
Example:
emif1: emif@0x4c000000 {
emif1: emif@4c000000 {
compatible = "ti,emif-4d";
ti,hwmods = "emif2";
phy-type = <1>;

2
Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt
View file

@ -13,7 +13,7 @@ Required properties:
Example:
devctrl: device-state-control@0x02620000 {
devctrl: device-state-control@02620000 {
compatible = "ti,keystone-devctrl", "syscon";
reg = <0x02620000 0x1000>;
};

2
Documentation/devicetree/bindings/misc/brcm,kona-smc.txt
View file

@ -9,7 +9,7 @@ Required properties:
- reg : Location and size of bounce buffer
Example:
smc@0x3404c000 {
smc@3404c000 {
compatible = "brcm,bcm11351-smc", "brcm,kona-smc";
reg = <0x3404c000 0x400>; //1 KiB in SRAM
};

2
Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt
View file

@ -12,7 +12,7 @@ Refer to clocks/clock-bindings.txt for generic clock consumer properties.
Example:
sdio2: sdio@0x3f1a0000 {
sdio2: sdio@3f1a0000 {
compatible = "brcm,kona-sdhci";
reg = <0x3f1a0000 0x10000>;
clocks = <&sdio3_clk>;

2
Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
View file

@ -24,7 +24,7 @@ Optional properties:
Example:
sdhci0: sdhci@0x18041000 {
sdhci0: sdhci@18041000 {
compatible = "brcm,sdhci-iproc-cygnus";
reg = <0x18041000 0x100>;
interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;

4
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
View file

@ -55,7 +55,7 @@ Examples:
[hwmod populated DMA resources]
mmc1: mmc@0x4809c000 {
mmc1: mmc@4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
ti,hwmods = "mmc1";
@ -67,7 +67,7 @@ Examples:
[generic DMA request binding]
mmc1: mmc@0x4809c000 {
mmc1: mmc@4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
ti,hwmods = "mmc1";

6
Documentation/devicetree/bindings/mtd/gpmc-nor.txt
View file

@ -82,15 +82,15 @@ gpmc: gpmc@6e000000 {
label = "bootloader-nor";
reg = <0 0x40000>;
};
partition@0x40000 {
partition@40000 {
label = "params-nor";
reg = <0x40000 0x40000>;
};
partition@0x80000 {
partition@80000 {
label = "kernel-nor";
reg = <0x80000 0x200000>;
};
partition@0x280000 {
partition@280000 {
label = "filesystem-nor";
reg = <0x240000 0x7d80000>;
};

2
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
View file

@ -13,7 +13,6 @@ Required properties:
at25df321a
at25df641
at26df081a
en25s64
mr25h128
mr25h256
mr25h10
@ -33,7 +32,6 @@ Required properties:
s25fl008k
s25fl064k
sst25vf040b
sst25wf040b
m25p40
m25p80
m25p16

2
Documentation/devicetree/bindings/mtd/mtk-nand.txt
View file

@ -131,7 +131,7 @@ Example:
read-only;
reg = <0x00000000 0x00400000>;
};
android@0x00400000 {
android@00400000 {
label = "android";
reg = <0x00400000 0x12c00000>;
};

4
Documentation/devicetree/bindings/net/altera_tse.txt
View file

@ -52,7 +52,7 @@ Optional properties:
Example:
tse_sub_0_eth_tse_0: ethernet@0x1,00000000 {
tse_sub_0_eth_tse_0: ethernet@1,00000000 {
compatible = "altr,tse-msgdma-1.0";
reg = <0x00000001 0x00000000 0x00000400>,
<0x00000001 0x00000460 0x00000020>,
@ -90,7 +90,7 @@ Example:
};
};
tse_sub_1_eth_tse_0: ethernet@0x1,00001000 {
tse_sub_1_eth_tse_0: ethernet@1,00001000 {
compatible = "altr,tse-msgdma-1.0";
reg = <0x00000001 0x00001000 0x00000400>,
<0x00000001 0x00001460 0x00000020>,

2
Documentation/devicetree/bindings/net/mdio.txt
View file

@ -18,7 +18,7 @@ Example :
This example shows these optional properties, plus other properties
required for the TI Davinci MDIO driver.
davinci_mdio: ethernet@0x5c030000 {
davinci_mdio: ethernet@5c030000 {
compatible = "ti,davinci_mdio";
reg = <0x5c030000 0x1000>;
#address-cells = <1>;

2
Documentation/devicetree/bindings/net/socfpga-dwmac.txt
View file

@ -28,7 +28,7 @@ Required properties:
Example:
gmii_to_sgmii_converter: phy@0x100000240 {
gmii_to_sgmii_converter: phy@100000240 {
compatible = "altr,gmii-to-sgmii-2.0";
reg = <0x00000001 0x00000240 0x00000008>,
<0x00000001 0x00000200 0x00000040>;

2
Documentation/devicetree/bindings/nios2/nios2.txt
View file

@ -36,7 +36,7 @@ Optional properties:
Example:
cpu@0x0 {
cpu@0 {
device_type = "cpu";
compatible = "altr,nios2-1.0";
reg = <0>;

2
Documentation/devicetree/bindings/pci/altera-pcie.txt
View file

@ -25,7 +25,7 @@ Optional properties:
- bus-range: PCI bus numbers covered
Example
pcie_0: pcie@0xc00000000 {
pcie_0: pcie@c00000000 {
compatible = "altr,pcie-root-port-1.0";
reg = <0xc0000000 0x20000000>,
<0xff220000 0x00004000>;

2
Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
View file

@ -52,7 +52,7 @@ Additional required properties for imx7d-pcie:
Example:
pcie@0x01000000 {
pcie@01000000 {
compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
reg = <0x01ffc000 0x04000>,
<0x01f00000 0x80000>;

2
Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
View file

@ -21,7 +21,7 @@ Optional properties:
- dma-coherent: Present if DMA operations are coherent.
Hip05 Example (note that Hip06 is the same except compatible):
pcie@0xb0080000 {
pcie@b0080000 {
compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
reg-names = "rc_dbi", "config";

2
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
View file

@ -45,7 +45,7 @@ Optional properties:
- usb3_vbus-supply : regulator phandle for controller usb3 vbus
Example:
usbphy: phy@0x01c13400 {
usbphy: phy@01c13400 {
#phy-cells = <1>;
compatible = "allwinner,sun4i-a10-usb-phy";
/* phy base regs, phy1 pmu reg, phy2 pmu reg */

2
Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt
View file

@ -25,7 +25,7 @@ Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
For example:
pinmux: pinmux@0x0301d0c8 {
pinmux: pinmux@0301d0c8 {
compatible = "brcm,cygnus-pinmux";
reg = <0x0301d0c8 0x1b0>;

4
Documentation/devicetree/bindings/pinctrl/pinctrl-atlas7.txt
View file

@ -96,14 +96,14 @@ For example, pinctrl might have subnodes like the following:
For a specific board, if it wants to use sd1,
it can add the following to its board-specific .dts file.
sd1: sd@0x12340000 {
sd1: sd@12340000 {
pinctrl-names = "default";
pinctrl-0 = <&sd1_pmx0>;
}
or
sd1: sd@0x12340000 {
sd1: sd@12340000 {
pinctrl-names = "default";
pinctrl-0 = <&sd1_pmx1>;
}

2
Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt
View file

@ -41,7 +41,7 @@ For example, pinctrl might have subnodes like the following:
For a specific board, if it wants to use uart2 without hardware flow control,
it can add the following to its board-specific .dts file.
uart2: uart@0xb0070000 {
uart2: uart@b0070000 {
pinctrl-names = "default";
pinctrl-0 = <&uart2_noflow_pins_a>;
}

4
Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
View file

@ -136,7 +136,7 @@ Example for rk3188:
#size-cells = <1>;
ranges;
gpio0: gpio0@0x2000a000 {
gpio0: gpio0@2000a000 {
compatible = "rockchip,rk3188-gpio-bank0";
reg = <0x2000a000 0x100>;
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
@ -149,7 +149,7 @@ Example for rk3188:
#interrupt-cells = <2>;
};
gpio1: gpio1@0x2003c000 {
gpio1: gpio1@2003c000 {
compatible = "rockchip,gpio-bank";
reg = <0x2003c000 0x100>;
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;

2
Documentation/devicetree/bindings/regulator/regulator.txt
View file

@ -107,7 +107,7 @@ regulators (twl_reg1 and twl_reg2),
...
};
mmc: mmc@0x0 {
mmc: mmc@0 {
...
...
vmmc-supply = <&twl_reg1>;

2
Documentation/devicetree/bindings/serial/efm32-uart.txt
View file

@ -12,7 +12,7 @@ Optional properties:
Example:
uart@0x4000c400 {
uart@4000c400 {
compatible = "energymicro,efm32-uart";
reg = <0x4000c400 0x400>;
interrupts = <15>;

2
Documentation/devicetree/bindings/serio/allwinner,sun4i-ps2.txt
View file

@ -14,7 +14,7 @@ Required properties:
Example:
ps20: ps2@0x01c2a000 {
ps20: ps2@01c2a000 {
compatible = "allwinner,sun4i-a10-ps2";
reg = <0x01c2a000 0x400>;
interrupts = <0 62 4>;

2
Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
View file

@ -220,7 +220,7 @@ qmss: qmss@2a40000 {
#address-cells = <1>;
#size-cells = <1>;
ranges;
pdsp0@0x2a10000 {
pdsp0@2a10000 {
reg = <0x2a10000 0x1000>,
<0x2a0f000 0x100>,
<0x2a0c000 0x3c8>,

2
Documentation/devicetree/bindings/sound/adi,axi-i2s.txt
View file

@ -21,7 +21,7 @@ please check:
Example:
i2s: i2s@0x77600000 {
i2s: i2s@77600000 {
compatible = "adi,axi-i2s-1.00.a";
reg = <0x77600000 0x1000>;
clocks = <&clk 15>, <&audio_clock>;

2
Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt
View file

@ -20,7 +20,7 @@ please check:
Example:
spdif: spdif@0x77400000 {
spdif: spdif@77400000 {
compatible = "adi,axi-spdif-tx-1.00.a";
reg = <0x77600000 0x1000>;
clocks = <&clk 15>, <&audio_clock>;

2
Documentation/devicetree/bindings/sound/ak4613.txt
View file

@ -20,7 +20,7 @@ Optional properties:
Example:
&i2c {
ak4613: ak4613@0x10 {
ak4613: ak4613@10 {
compatible = "asahi-kasei,ak4613";
reg = <0x10>;
};

2
Documentation/devicetree/bindings/sound/ak4642.txt
View file

@ -17,7 +17,7 @@ Optional properties:
Example 1:
&i2c {
ak4648: ak4648@0x12 {
ak4648: ak4648@12 {
compatible = "asahi-kasei,ak4642";
reg = <0x12>;
};

2
Documentation/devicetree/bindings/sound/da7218.txt
View file

@ -73,7 +73,7 @@ Example:
compatible = "dlg,da7218";
reg = <0x1a>;
interrupt-parent = <&gpio6>;
interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
wakeup-source;
VDD-supply = <&reg_audio>;

2
Documentation/devicetree/bindings/sound/da7219.txt
View file

@ -77,7 +77,7 @@ Example:
reg = <0x1a>;
interrupt-parent = <&gpio6>;
interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
VDD-supply = <&reg_audio>;
VDDMIC-supply = <&reg_audio>;

2
Documentation/devicetree/bindings/sound/max98371.txt
View file

@ -10,7 +10,7 @@ Required properties:
Example:
&i2c {
max98371: max98371@0x31 {
max98371: max98371@31 {
compatible = "maxim,max98371";
reg = <0x31>;
};

2
Documentation/devicetree/bindings/sound/max9867.txt
View file

@ -10,7 +10,7 @@ Required properties:
Example:
&i2c {
max9867: max9867@0x18 {
max9867: max9867@18 {
compatible = "maxim,max9867";
reg = <0x18>;
};

2
Documentation/devicetree/bindings/sound/renesas,fsi.txt
View file

@ -20,7 +20,7 @@ Required properties:
Example:
sh_fsi2: sh_fsi2@0xec230000 {
sh_fsi2: sh_fsi2@ec230000 {
compatible = "renesas,sh_fsi2";
reg = <0xec230000 0x400>;
interrupts = <0 146 0x4>;

2
Documentation/devicetree/bindings/sound/rockchip-spdif.txt
View file

@ -33,7 +33,7 @@ Required properties on RK3288:
Example for the rk3188 SPDIF controller:
spdif: spdif@0x1011e000 {
spdif: spdif@1011e000 {
compatible = "rockchip,rk3188-spdif", "rockchip,rk3066-spdif";
reg = <0x1011e000 0x2000>;
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;

8
Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt
View file

@ -51,7 +51,7 @@ Optional properties:
Example:
sti_uni_player1: sti-uni-player@0x8D81000 {
sti_uni_player1: sti-uni-player@8D81000 {
compatible = "st,stih407-uni-player-hdmi";
#sound-dai-cells = <0>;
st,syscfg = <&syscfg_core>;
@ -63,7 +63,7 @@ Example:
st,tdm-mode = <1>;
};
sti_uni_player2: sti-uni-player@0x8D82000 {
sti_uni_player2: sti-uni-player@8D82000 {
compatible = "st,stih407-uni-player-pcm-out";
#sound-dai-cells = <0>;
st,syscfg = <&syscfg_core>;
@ -74,7 +74,7 @@ Example:
dma-names = "tx";
};
sti_uni_player3: sti-uni-player@0x8D85000 {
sti_uni_player3: sti-uni-player@8D85000 {
compatible = "st,stih407-uni-player-spdif";
#sound-dai-cells = <0>;
st,syscfg = <&syscfg_core>;
@ -85,7 +85,7 @@ Example:
dma-names = "tx";
};
sti_uni_reader1: sti-uni-reader@0x8D84000 {
sti_uni_reader1: sti-uni-reader@8D84000 {
compatible = "st,stih407-uni-reader-hdmi";
#sound-dai-cells = <0>;
st,syscfg = <&syscfg_core>;

2
Documentation/devicetree/bindings/spi/efm32-spi.txt
View file

@ -19,7 +19,7 @@ Recommended properties :
Example:
spi1: spi@0x4000c400 { /* USART1 */
spi1: spi@4000c400 { /* USART1 */
#address-cells = <1>;
#size-cells = <0>;
compatible = "energymicro,efm32-spi";

18
Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
View file

@ -12,24 +12,30 @@ Required properties:
- "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53 and later Soc
- reg : Offset and length of the register set for the device
- interrupts : Should contain CSPI/eCSPI interrupt
- cs-gpios : Specifies the gpio pins to be used for chipselects.
- clocks : Clock specifiers for both ipg and per clocks.
- clock-names : Clock names should include both "ipg" and "per"
See the clock consumer binding,
Documentation/devicetree/bindings/clock/clock-bindings.txt
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt
- dma-names: DMA request names should include "tx" and "rx" if present.
Obsolete properties:
- fsl,spi-num-chipselects : Contains the number of the chipselect
Recommended properties:
- cs-gpios : GPIOs to use as chip selects, see spi-bus.txt. While the native chip
select lines can be used, they appear to always generate a pulse between each
word of a transfer. Most use cases will require GPIO based chip selects to
generate a valid transaction.
Optional properties:
- num-cs : Number of total chip selects, see spi-bus.txt.
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt.
- dma-names: DMA request names, if present, should include "tx" and "rx".
- fsl,spi-rdy-drctl: Integer, representing the value of DRCTL, the register
controlling the SPI_READY handling. Note that to enable the DRCTL consideration,
the SPI_READY mode-flag needs to be set too.
Valid values are: 0 (disabled), 1 (edge-triggered burst) and 2 (level-triggered burst).
Obsolete properties:
- fsl,spi-num-chipselects : Contains the number of the chipselect
Example:
ecspi@70010000 {

12
Documentation/devicetree/bindings/thermal/thermal.txt
View file

@ -239,7 +239,7 @@ cpus {
* A simple fan controller which supports 10 speeds of operation
* (represented as 0-9).
*/
fan0: fan@0x48 {
fan0: fan@48 {
...
cooling-min-level = <0>;
cooling-max-level = <9>;
@ -252,7 +252,7 @@ ocp {
/*
* A simple IC with a single bandgap temperature sensor.
*/
bandgap0: bandgap@0x0000ED00 {
bandgap0: bandgap@0000ED00 {
...
#thermal-sensor-cells = <0>;
};
@ -330,7 +330,7 @@ ocp {
/*
* A simple IC with several bandgap temperature sensors.
*/
bandgap0: bandgap@0x0000ED00 {
bandgap0: bandgap@0000ED00 {
...
#thermal-sensor-cells = <1>;
};
@ -447,7 +447,7 @@ one thermal zone.
/*
* A simple IC with a single temperature sensor.
*/
adc: sensor@0x49 {
adc: sensor@49 {
...
#thermal-sensor-cells = <0>;
};
@ -458,7 +458,7 @@ ocp {
/*
* A simple IC with a single bandgap temperature sensor.
*/
bandgap0: bandgap@0x0000ED00 {
bandgap0: bandgap@0000ED00 {
...
#thermal-sensor-cells = <0>;
};
@ -516,7 +516,7 @@ with many sensors and many cooling devices.
/*
* An IC with several temperature sensor.
*/
adc_dummy: sensor@0x50 {
adc_dummy: sensor@50 {
...
#thermal-sensor-cells = <1>; /* sensor internal ID */
};

4
Documentation/devicetree/bindings/ufs/ufs-qcom.txt
View file

@ -32,7 +32,7 @@ Optional properties:
Example:
ufsphy1: ufsphy@0xfc597000 {
ufsphy1: ufsphy@fc597000 {
compatible = "qcom,ufs-phy-qmp-20nm";
reg = <0xfc597000 0x800>;
reg-names = "phy_mem";
@ -53,7 +53,7 @@ Example:
<&clock_gcc clk_gcc_ufs_rx_cfg_clk>;
};
ufshc@0xfc598000 {
ufshc@fc598000 {
...
phys = <&ufsphy1>;
phy-names = "ufsphy";

2
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
View file

@ -46,7 +46,7 @@ Note: If above properties are not defined it can be assumed that the supply
regulators or clocks are always on.
Example:
ufshc@0xfc598000 {
ufshc@fc598000 {
compatible = "jedec,ufs-1.1";
reg = <0xfc598000 0x800>;
interrupts = <0 28 0>;

2
Documentation/devicetree/bindings/usb/am33xx-usb.txt
View file

@ -95,6 +95,7 @@ usb: usb@47400000 {
reg = <0x47401300 0x100>;
reg-names = "phy";
ti,ctrl_mod = <&ctrl_mod>;
#phy-cells = <0>;
};
usb0: usb@47401000 {
@ -141,6 +142,7 @@ usb: usb@47400000 {
reg = <0x47401b00 0x100>;
reg-names = "phy";
ti,ctrl_mod = <&ctrl_mod>;
#phy-cells = <0>;
};
usb1: usb@47401800 {

2
Documentation/devicetree/bindings/usb/ehci-st.txt
View file

@ -22,7 +22,7 @@ See: Documentation/devicetree/bindings/reset/reset.txt
Example:
ehci1: usb@0xfe203e00 {
ehci1: usb@fe203e00 {
compatible = "st,st-ehci-300x";
reg = <0xfe203e00 0x100>;
interrupts = <GIC_SPI 148 IRQ_TYPE_NONE>;

2
Documentation/devicetree/bindings/usb/ohci-st.txt
View file

@ -20,7 +20,7 @@ See: Documentation/devicetree/bindings/reset/reset.txt
Example:
ohci0: usb@0xfe1ffc00 {
ohci0: usb@fe1ffc00 {
compatible = "st,st-ohci-300x";
reg = <0xfe1ffc00 0x100>;
interrupts = <GIC_SPI 149 IRQ_TYPE_NONE>;

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

@ -6,7 +6,7 @@ reg: Register address and length for watchdog registers
Example:
watchdog: jz4740-watchdog@0x10002000 {
watchdog: jz4740-watchdog@10002000 {
compatible = "ingenic,jz4740-watchdog";
reg = <0x10002000 0x100>;
};

34
Documentation/filesystems/overlayfs.txt
View file

@ -156,6 +156,40 @@ handle it in two different ways:
root of the overlay. Finally the directory is moved to the new
location.
There are several ways to tune the "redirect_dir" feature.
Kernel config options:
- OVERLAY_FS_REDIRECT_DIR:
If this is enabled, then redirect_dir is turned on by default.
- OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW:
If this is enabled, then redirects are always followed by default. Enabling
this results in a less secure configuration. Enable this option only when
worried about backward compatibility with kernels that have the redirect_dir
feature and follow redirects even if turned off.
Module options (can also be changed through /sys/module/overlay/parameters/*):
- "redirect_dir=BOOL":
See OVERLAY_FS_REDIRECT_DIR kernel config option above.
- "redirect_always_follow=BOOL":
See OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW kernel config option above.
- "redirect_max=NUM":
The maximum number of bytes in an absolute redirect (default is 256).
Mount options:
- "redirect_dir=on":
Redirects are enabled.
- "redirect_dir=follow":
Redirects are not created, but followed.
- "redirect_dir=off":
Redirects are not created and only followed if "redirect_always_follow"
feature is enabled in the kernel/module config.
- "redirect_dir=nofollow":
Redirects are not created and not followed (equivalent to "redirect_dir=off"
if "redirect_always_follow" feature is not enabled).
Non-directories
---------------

5
Documentation/gpu/i915.rst
View file

@ -341,10 +341,7 @@ GuC
GuC-specific firmware loader
----------------------------
.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
:doc: GuC-specific firmware loader
.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:internal:
GuC-based command submission

874
Documentation/locking/crossrelease.txt
View file

@ -1,874 +0,0 @@
Crossrelease
============
Started by Byungchul Park <byungchul.park@lge.com>
Contents:
(*) Background
- What causes deadlock
- How lockdep works
(*) Limitation
- Limit lockdep
- Pros from the limitation
- Cons from the limitation
- Relax the limitation
(*) Crossrelease
- Introduce crossrelease
- Introduce commit
(*) Implementation
- Data structures
- How crossrelease works
(*) Optimizations
- Avoid duplication
- Lockless for hot paths
(*) APPENDIX A: What lockdep does to work aggresively
(*) APPENDIX B: How to avoid adding false dependencies
==========
Background
==========
What causes deadlock
--------------------
A deadlock occurs when a context is waiting for an event to happen,
which is impossible because another (or the) context who can trigger the
event is also waiting for another (or the) event to happen, which is
also impossible due to the same reason.
For example:
A context going to trigger event C is waiting for event A to happen.
A context going to trigger event A is waiting for event B to happen.
A context going to trigger event B is waiting for event C to happen.
A deadlock occurs when these three wait operations run at the same time,
because event C cannot be triggered if event A does not happen, which in
turn cannot be triggered if event B does not happen, which in turn
cannot be triggered if event C does not happen. After all, no event can
be triggered since any of them never meets its condition to wake up.
A dependency might exist between two waiters and a deadlock might happen
due to an incorrect releationship between dependencies. Thus, we must
define what a dependency is first. A dependency exists between them if:
1. There are two waiters waiting for each event at a given time.
2. The only way to wake up each waiter is to trigger its event.
3. Whether one can be woken up depends on whether the other can.
Each wait in the example creates its dependency like:
Event C depends on event A.
Event A depends on event B.
Event B depends on event C.
NOTE: Precisely speaking, a dependency is one between whether a
waiter for an event can be woken up and whether another waiter for
another event can be woken up. However from now on, we will describe
a dependency as if it's one between an event and another event for
simplicity.
And they form circular dependencies like:
-> C -> A -> B -
/ \
\ /
----------------
where 'A -> B' means that event A depends on event B.
Such circular dependencies lead to a deadlock since no waiter can meet
its condition to wake up as described.
CONCLUSION
Circular dependencies cause a deadlock.
How lockdep works
-----------------
Lockdep tries to detect a deadlock by checking dependencies created by
lock operations, acquire and release. Waiting for a lock corresponds to
waiting for an event, and releasing a lock corresponds to triggering an
event in the previous section.
In short, lockdep does:
1. Detect a new dependency.
2. Add the dependency into a global graph.
3. Check if that makes dependencies circular.
4. Report a deadlock or its possibility if so.
For example, consider a graph built by lockdep that looks like:
A -> B -
\
-> E
/
C -> D -
where A, B,..., E are different lock classes.
Lockdep will add a dependency into the graph on detection of a new
dependency. For example, it will add a dependency 'E -> C' when a new
dependency between lock E and lock C is detected. Then the graph will be:
A -> B -
\
-> E -
/ \
-> C -> D - \
/ /
\ /
------------------
where A, B,..., E are different lock classes.
This graph contains a subgraph which demonstrates circular dependencies:
-> E -
/ \
-> C -> D - \
/ /
\ /
------------------
where C, D and E are different lock classes.
This is the condition under which a deadlock might occur. Lockdep
reports it on detection after adding a new dependency. This is the way
how lockdep works.
CONCLUSION
Lockdep detects a deadlock or its possibility by checking if circular
dependencies were created after adding each new dependency.
==========
Limitation
==========
Limit lockdep
-------------
Limiting lockdep to work on only typical locks e.g. spin locks and
mutexes, which are released within the acquire context, the
implementation becomes simple but its capacity for detection becomes
limited. Let's check pros and cons in next section.
Pros from the limitation
------------------------
Given the limitation, when acquiring a lock, locks in a held_locks
cannot be released if the context cannot acquire it so has to wait to
acquire it, which means all waiters for the locks in the held_locks are
stuck. It's an exact case to create dependencies between each lock in
the held_locks and the lock to acquire.
For example:
CONTEXT X
---------
acquire A
acquire B /* Add a dependency 'A -> B' */
release B
release A
where A and B are different lock classes.
When acquiring lock A, the held_locks of CONTEXT X is empty thus no
dependency is added. But when acquiring lock B, lockdep detects and adds
a new dependency 'A -> B' between lock A in the held_locks and lock B.
They can be simply added whenever acquiring each lock.
And data required by lockdep exists in a local structure, held_locks
embedded in task_struct. Forcing to access the data within the context,
lockdep can avoid racy problems without explicit locks while handling
the local data.
Lastly, lockdep only needs to keep locks currently being held, to build
a dependency graph. However, relaxing the limitation, it needs to keep
even locks already released, because a decision whether they created
dependencies might be long-deferred.
To sum up, we can expect several advantages from the limitation:
1. Lockdep can easily identify a dependency when acquiring a lock.
2. Races are avoidable while accessing local locks in a held_locks.
3. Lockdep only needs to keep locks currently being held.
CONCLUSION
Given the limitation, the implementation becomes simple and efficient.
Cons from the limitation
------------------------
Given the limitation, lockdep is applicable only to typical locks. For
example, page locks for page access or completions for synchronization
cannot work with lockdep.
Can we detect deadlocks below, under the limitation?
Example 1:
CONTEXT X CONTEXT Y CONTEXT Z
--------- --------- ----------
mutex_lock A
lock_page B
lock_page B
mutex_lock A /* DEADLOCK */
unlock_page B held by X
unlock_page B
mutex_unlock A
mutex_unlock A
where A and B are different lock classes.
No, we cannot.
Example 2:
CONTEXT X CONTEXT Y
--------- ---------
mutex_lock A
mutex_lock A
wait_for_complete B /* DEADLOCK */
complete B
mutex_unlock A
mutex_unlock A
where A is a lock class and B is a completion variable.
No, we cannot.
CONCLUSION
Given the limitation, lockdep cannot detect a deadlock or its
possibility caused by page locks or completions.
Relax the limitation
--------------------
Under the limitation, things to create dependencies are limited to
typical locks. However, synchronization primitives like page locks and
completions, which are allowed to be released in any context, also
create dependencies and can cause a deadlock. So lockdep should track
these locks to do a better job. We have to relax the limitation for
these locks to work with lockdep.
Detecting dependencies is very important for lockdep to work because
adding a dependency means adding an opportunity to check whether it
causes a deadlock. The more lockdep adds dependencies, the more it
thoroughly works. Thus Lockdep has to do its best to detect and add as
many true dependencies into a graph as possible.
For example, considering only typical locks, lockdep builds a graph like:
A -> B -
\
-> E
/
C -> D -
where A, B,..., E are different lock classes.
On the other hand, under the relaxation, additional dependencies might
be created and added. Assuming additional 'FX -> C' and 'E -> GX' are
added thanks to the relaxation, the graph will be:
A -> B -
\
-> E -> GX
/
FX -> C -> D -
where A, B,..., E, FX and GX are different lock classes, and a suffix
'X' is added on non-typical locks.
The latter graph gives us more chances to check circular dependencies
than the former. However, it might suffer performance degradation since
relaxing the limitation, with which design and implementation of lockdep
can be efficient, might introduce inefficiency inevitably. So lockdep
should provide two options, strong detection and efficient detection.
Choosing efficient detection:
Lockdep works with only locks restricted to be released within the
acquire context. However, lockdep works efficiently.
Choosing strong detection:
Lockdep works with all synchronization primitives. However, lockdep
suffers performance degradation.
CONCLUSION
Relaxing the limitation, lockdep can add additional dependencies giving
additional opportunities to check circular dependencies.
============
Crossrelease
============
Introduce crossrelease
----------------------
In order to allow lockdep to handle additional dependencies by what
might be released in any context, namely 'crosslock', we have to be able
to identify those created by crosslocks. The proposed 'crossrelease'
feature provoides a way to do that.
Crossrelease feature has to do:
1. Identify dependencies created by crosslocks.
2. Add the dependencies into a dependency graph.
That's all. Once a meaningful dependency is added into graph, then
lockdep would work with the graph as it did. The most important thing
crossrelease feature has to do is to correctly identify and add true
dependencies into the global graph.
A dependency e.g. 'A -> B' can be identified only in the A's release
context because a decision required to identify the dependency can be
made only in the release context. That is to decide whether A can be
released so that a waiter for A can be woken up. It cannot be made in
other than the A's release context.
It's no matter for typical locks because each acquire context is same as
its release context, thus lockdep can decide whether a lock can be
released in the acquire context. However for crosslocks, lockdep cannot
make the decision in the acquire context but has to wait until the
release context is identified.
Therefore, deadlocks by crosslocks cannot be detected just when it
happens, because those cannot be identified until the crosslocks are
released. However, deadlock possibilities can be detected and it's very
worth. See 'APPENDIX A' section to check why.
CONCLUSION
Using crossrelease feature, lockdep can work with what might be released
in any context, namely crosslock.
Introduce commit
----------------
Since crossrelease defers the work adding true dependencies of
crosslocks until they are actually released, crossrelease has to queue
all acquisitions which might create dependencies with the crosslocks.
Then it identifies dependencies using the queued data in batches at a
proper time. We call it 'commit'.
There are four types of dependencies:
1. TT type: 'typical lock A -> typical lock B'
Just when acquiring B, lockdep can see it's in the A's release
context. So the dependency between A and B can be identified
immediately. Commit is unnecessary.
2. TC type: 'typical lock A -> crosslock BX'
Just when acquiring BX, lockdep can see it's in the A's release
context. So the dependency between A and BX can be identified
immediately. Commit is unnecessary, too.
3. CT type: 'crosslock AX -> typical lock B'
When acquiring B, lockdep cannot identify the dependency because
there's no way to know if it's in the AX's release context. It has
to wait until the decision can be made. Commit is necessary.
4. CC type: 'crosslock AX -> crosslock BX'
When acquiring BX, lockdep cannot identify the dependency because
there's no way to know if it's in the AX's release context. It has
to wait until the decision can be made. Commit is necessary.
But, handling CC type is not implemented yet. It's a future work.
Lockdep can work without commit for typical locks, but commit step is
necessary once crosslocks are involved. Introducing commit, lockdep
performs three steps. What lockdep does in each step is:
1. Acquisition: For typical locks, lockdep does what it originally did
and queues the lock so that CT type dependencies can be checked using
it at the commit step. For crosslocks, it saves data which will be
used at the commit step and increases a reference count for it.
2. Commit: No action is reauired for typical locks. For crosslocks,
lockdep adds CT type dependencies using the data saved at the
acquisition step.
3. Release: No changes are required for typical locks. When a crosslock
is released, it decreases a reference count for it.
CONCLUSION
Crossrelease introduces commit step to handle dependencies of crosslocks
in batches at a proper time.
==============
Implementation
==============
Data structures
---------------
Crossrelease introduces two main data structures.
1. hist_lock
This is an array embedded in task_struct, for keeping lock history so
that dependencies can be added using them at the commit step. Since
it's local data, it can be accessed locklessly in the owner context.
The array is filled at the acquisition step and consumed at the
commit step. And it's managed in circular manner.
2. cross_lock
One per lockdep_map exists. This is for keeping data of crosslocks
and used at the commit step.
How crossrelease works
----------------------
It's the key of how crossrelease works, to defer necessary works to an
appropriate point in time and perform in at once at the commit step.
Let's take a look with examples step by step, starting from how lockdep
works without crossrelease for typical locks.
acquire A /* Push A onto held_locks */
acquire B /* Push B onto held_locks and add 'A -> B' */
acquire C /* Push C onto held_locks and add 'B -> C' */
release C /* Pop C from held_locks */
release B /* Pop B from held_locks */
release A /* Pop A from held_locks */
where A, B and C are different lock classes.
NOTE: This document assumes that readers already understand how
lockdep works without crossrelease thus omits details. But there's
one thing to note. Lockdep pretends to pop a lock from held_locks
when releasing it. But it's subtly different from the original pop
operation because lockdep allows other than the top to be poped.
In this case, lockdep adds 'the top of held_locks -> the lock to acquire'
dependency every time acquiring a lock.
After adding 'A -> B', a dependency graph will be:
A -> B
where A and B are different lock classes.
And after adding 'B -> C', the graph will be:
A -> B -> C
where A, B and C are different lock classes.
Let's performs commit step even for typical locks to add dependencies.
Of course, commit step is not necessary for them, however, it would work
well because this is a more general way.
acquire A
/*
* Queue A into hist_locks
*
* In hist_locks: A
* In graph: Empty
*/
acquire B
/*
* Queue B into hist_locks
*
* In hist_locks: A, B
* In graph: Empty
*/
acquire C
/*
* Queue C into hist_locks
*
* In hist_locks: A, B, C
* In graph: Empty
*/
commit C
/*
* Add 'C -> ?'
* Answer the following to decide '?'
* What has been queued since acquire C: Nothing
*
* In hist_locks: A, B, C
* In graph: Empty
*/
release C
commit B
/*
* Add 'B -> ?'
* Answer the following to decide '?'
* What has been queued since acquire B: C
*
* In hist_locks: A, B, C
* In graph: 'B -> C'
*/
release B
commit A
/*
* Add 'A -> ?'
* Answer the following to decide '?'
* What has been queued since acquire A: B, C
*
* In hist_locks: A, B, C
* In graph: 'B -> C', 'A -> B', 'A -> C'
*/
release A
where A, B and C are different lock classes.
In this case, dependencies are added at the commit step as described.
After commits for A, B and C, the graph will be:
A -> B -> C
where A, B and C are different lock classes.
NOTE: A dependency 'A -> C' is optimized out.
We can see the former graph built without commit step is same as the
latter graph built using commit steps. Of course the former way leads to
earlier finish for building the graph, which means we can detect a
deadlock or its possibility sooner. So the former way would be prefered
when possible. But we cannot avoid using the latter way for crosslocks.
Let's look at how commit steps work for crosslocks. In this case, the
commit step is performed only on crosslock AX as real. And it assumes
that the AX release context is different from the AX acquire context.
BX RELEASE CONTEXT BX ACQUIRE CONTEXT
------------------ ------------------
acquire A
/*
* Push A onto held_locks
* Queue A into hist_locks
*
* In held_locks: A
* In hist_locks: A
* In graph: Empty
*/
acquire BX
/*
* Add 'the top of held_locks -> BX'
*
* In held_locks: A
* In hist_locks: A
* In graph: 'A -> BX'
*/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It must be guaranteed that the following operations are seen after
acquiring BX globally. It can be done by things like barrier.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
acquire C
/*
* Push C onto held_locks
* Queue C into hist_locks
*
* In held_locks: C
* In hist_locks: C
* In graph: 'A -> BX'
*/
release C
/*
* Pop C from held_locks
*
* In held_locks: Empty
* In hist_locks: C
* In graph: 'A -> BX'
*/
acquire D
/*
* Push D onto held_locks
* Queue D into hist_locks
* Add 'the top of held_locks -> D'
*
* In held_locks: A, D
* In hist_locks: A, D
* In graph: 'A -> BX', 'A -> D'
*/
acquire E
/*
* Push E onto held_locks
* Queue E into hist_locks
*
* In held_locks: E
* In hist_locks: C, E
* In graph: 'A -> BX', 'A -> D'
*/
release E
/*
* Pop E from held_locks
*
* In held_locks: Empty
* In hist_locks: D, E
* In graph: 'A -> BX', 'A -> D'
*/
release D
/*
* Pop D from held_locks
*
* In held_locks: A
* In hist_locks: A, D
* In graph: 'A -> BX', 'A -> D'
*/
commit BX
/*
* Add 'BX -> ?'
* What has been queued since acquire BX: C, E
*
* In held_locks: Empty
* In hist_locks: D, E
* In graph: 'A -> BX', 'A -> D',
* 'BX -> C', 'BX -> E'
*/
release BX
/*
* In held_locks: Empty
* In hist_locks: D, E
* In graph: 'A -> BX', 'A -> D',
* 'BX -> C', 'BX -> E'
*/
release A
/*
* Pop A from held_locks
*
* In held_locks: Empty
* In hist_locks: A, D
* In graph: 'A -> BX', 'A -> D',
* 'BX -> C', 'BX -> E'
*/
where A, BX, C,..., E are different lock classes, and a suffix 'X' is
added on crosslocks.
Crossrelease considers all acquisitions after acqiuring BX are
candidates which might create dependencies with BX. True dependencies
will be determined when identifying the release context of BX. Meanwhile,
all typical locks are queued so that they can be used at the commit step.
And then two dependencies 'BX -> C' and 'BX -> E' are added at the
commit step when identifying the release context.
The final graph will be, with crossrelease:
-> C
/
-> BX -
/ \
A - -> E
\
-> D
where A, BX, C,..., E are different lock classes, and a suffix 'X' is
added on crosslocks.
However, the final graph will be, without crossrelease:
A -> D
where A and D are different lock classes.
The former graph has three more dependencies, 'A -> BX', 'BX -> C' and
'BX -> E' giving additional opportunities to check if they cause
deadlocks. This way lockdep can detect a deadlock or its possibility
caused by crosslocks.
CONCLUSION
We checked how crossrelease works with several examples.
=============
Optimizations
=============
Avoid duplication
-----------------
Crossrelease feature uses a cache like what lockdep already uses for
dependency chains, but this time it's for caching CT type dependencies.
Once that dependency is cached, the same will never be added again.
Lockless for hot paths
----------------------
To keep all locks for later use at the commit step, crossrelease adopts
a local array embedded in task_struct, which makes access to the data
lockless by forcing it to happen only within the owner context. It's
like how lockdep handles held_locks. Lockless implmentation is important
since typical locks are very frequently acquired and released.
=================================================
APPENDIX A: What lockdep does to work aggresively
=================================================
A deadlock actually occurs when all wait operations creating circular
dependencies run at the same time. Even though they don't, a potential
deadlock exists if the problematic dependencies exist. Thus it's
meaningful to detect not only an actual deadlock but also its potential
possibility. The latter is rather valuable. When a deadlock occurs
actually, we can identify what happens in the system by some means or
other even without lockdep. However, there's no way to detect possiblity
without lockdep unless the whole code is parsed in head. It's terrible.
Lockdep does the both, and crossrelease only focuses on the latter.
Whether or not a deadlock actually occurs depends on several factors.
For example, what order contexts are switched in is a factor. Assuming
circular dependencies exist, a deadlock would occur when contexts are
switched so that all wait operations creating the dependencies run
simultaneously. Thus to detect a deadlock possibility even in the case
that it has not occured yet, lockdep should consider all possible
combinations of dependencies, trying to:
1. Use a global dependency graph.
Lockdep combines all dependencies into one global graph and uses them,
regardless of which context generates them or what order contexts are
switched in. Aggregated dependencies are only considered so they are
prone to be circular if a problem exists.
2. Check dependencies between classes instead of instances.
What actually causes a deadlock are instances of lock. However,
lockdep checks dependencies between classes instead of instances.
This way lockdep can detect a deadlock which has not happened but
might happen in future by others but the same class.
3. Assume all acquisitions lead to waiting.
Although locks might be acquired without waiting which is essential
to create dependencies, lockdep assumes all acquisitions lead to
waiting since it might be true some time or another.
CONCLUSION
Lockdep detects not only an actual deadlock but also its possibility,
and the latter is more valuable.
==================================================
APPENDIX B: How to avoid adding false dependencies
==================================================
Remind what a dependency is. A dependency exists if:
1. There are two waiters waiting for each event at a given time.
2. The only way to wake up each waiter is to trigger its event.
3. Whether one can be woken up depends on whether the other can.
For example:
acquire A
acquire B /* A dependency 'A -> B' exists */
release B
release A
where A and B are different lock classes.
A depedency 'A -> B' exists since:
1. A waiter for A and a waiter for B might exist when acquiring B.
2. Only way to wake up each is to release what it waits for.
3. Whether the waiter for A can be woken up depends on whether the
other can. IOW, TASK X cannot release A if it fails to acquire B.
For another example:
TASK X TASK Y
------ ------
acquire AX
acquire B /* A dependency 'AX -> B' exists */
release B
release AX held by Y
where AX and B are different lock classes, and a suffix 'X' is added
on crosslocks.
Even in this case involving crosslocks, the same rule can be applied. A
depedency 'AX -> B' exists since:
1. A waiter for AX and a waiter for B might exist when acquiring B.
2. Only way to wake up each is to release what it waits for.
3. Whether the waiter for AX can be woken up depends on whether the
other can. IOW, TASK X cannot release AX if it fails to acquire B.
Let's take a look at more complicated example:
TASK X TASK Y
------ ------
acquire B
release B
fork Y
acquire AX
acquire C /* A dependency 'AX -> C' exists */
release C
release AX held by Y
where AX, B and C are different lock classes, and a suffix 'X' is
added on crosslocks.
Does a dependency 'AX -> B' exist? Nope.
Two waiters are essential to create a dependency. However, waiters for
AX and B to create 'AX -> B' cannot exist at the same time in this
example. Thus the dependency 'AX -> B' cannot be created.
It would be ideal if the full set of true ones can be considered. But
we can ensure nothing but what actually happened. Relying on what
actually happens at runtime, we can anyway add only true ones, though
they might be a subset of true ones. It's similar to how lockdep works
for typical locks. There might be more true dependencies than what
lockdep has detected in runtime. Lockdep has no choice but to rely on
what actually happens. Crossrelease also relies on it.
CONCLUSION
Relying on what actually happens, lockdep can avoid adding false
dependencies.

30
Documentation/media/dvb-drivers/frontends.rst Normal file
View file

@ -0,0 +1,30 @@
****************
Frontend drivers
****************
Frontend attach headers
***********************
.. Keep it on alphabetic order
.. kernel-doc:: drivers/media/dvb-frontends/a8293.h
.. kernel-doc:: drivers/media/dvb-frontends/af9013.h
.. kernel-doc:: drivers/media/dvb-frontends/ascot2e.h
.. kernel-doc:: drivers/media/dvb-frontends/cxd2820r.h
.. kernel-doc:: drivers/media/dvb-frontends/drxk.h
.. kernel-doc:: drivers/media/dvb-frontends/dvb-pll.h
.. kernel-doc:: drivers/media/dvb-frontends/helene.h
.. kernel-doc:: drivers/media/dvb-frontends/horus3a.h
.. kernel-doc:: drivers/media/dvb-frontends/ix2505v.h
.. kernel-doc:: drivers/media/dvb-frontends/m88ds3103.h
.. kernel-doc:: drivers/media/dvb-frontends/mb86a20s.h
.. kernel-doc:: drivers/media/dvb-frontends/mn88472.h
.. kernel-doc:: drivers/media/dvb-frontends/rtl2830.h
.. kernel-doc:: drivers/media/dvb-frontends/rtl2832.h
.. kernel-doc:: drivers/media/dvb-frontends/rtl2832_sdr.h
.. kernel-doc:: drivers/media/dvb-frontends/stb6000.h
.. kernel-doc:: drivers/media/dvb-frontends/tda10071.h
.. kernel-doc:: drivers/media/dvb-frontends/tda826x.h
.. kernel-doc:: drivers/media/dvb-frontends/zd1301_demod.h
.. kernel-doc:: drivers/media/dvb-frontends/zl10036.h

1
Documentation/media/dvb-drivers/index.rst
View file

@ -41,4 +41,5 @@ For more details see the file COPYING in the source distribution of Linux.
technisat
ttusb-dec
udev
frontends
contributors

15
Documentation/virtual/kvm/api.txt
View file

@ -2901,14 +2901,19 @@ userspace buffer and its length:
struct kvm_s390_irq_state {
__u64 buf;
__u32 flags;
__u32 flags; /* will stay unused for compatibility reasons */
__u32 len;
__u32 reserved[4];
__u32 reserved[4]; /* will stay unused for compatibility reasons */
};
Userspace passes in the above struct and for each pending interrupt a
struct kvm_s390_irq is copied to the provided buffer.
The structure contains a flags and a reserved field for future extensions. As
the kernel never checked for flags == 0 and QEMU never pre-zeroed flags and
reserved, these fields can not be used in the future without breaking
compatibility.
If -ENOBUFS is returned the buffer provided was too small and userspace
may retry with a bigger buffer.
@ -2932,10 +2937,14 @@ containing a struct kvm_s390_irq_state:
struct kvm_s390_irq_state {
__u64 buf;
__u32 flags; /* will stay unused for compatibility reasons */
__u32 len;
__u32 pad;
__u32 reserved[4]; /* will stay unused for compatibility reasons */
};
The restrictions for flags and reserved apply as well.
(see KVM_S390_GET_IRQ_STATE)
The userspace memory referenced by buf contains a struct kvm_s390_irq
for each interrupt to be injected into the guest.
If one of the interrupts could not be injected for some reason the

22
Documentation/vm/zswap.txt
View file

@ -98,5 +98,25 @@ request is made for a page in an old zpool, it is uncompressed using its
original compressor. Once all pages are removed from an old zpool, the zpool
and its compressor are freed.
Some of the pages in zswap are same-value filled pages (i.e. contents of the
page have same value or repetitive pattern). These pages include zero-filled
pages and they are handled differently. During store operation, a page is
checked if it is a same-value filled page before compressing it. If true, the
compressed length of the page is set to zero and the pattern or same-filled
value is stored.
Same-value filled pages identification feature is enabled by default and can be
disabled at boot time by setting the "same_filled_pages_enabled" attribute to 0,
e.g. zswap.same_filled_pages_enabled=0. It can also be enabled and disabled at
runtime using the sysfs "same_filled_pages_enabled" attribute, e.g.
echo 1 > /sys/module/zswap/parameters/same_filled_pages_enabled
When zswap same-filled page identification is disabled at runtime, it will stop
checking for the same-value filled pages during store operation. However, the
existing pages which are marked as same-value filled pages remain stored
unchanged in zswap until they are either loaded or invalidated.
A debugfs interface is provided for various statistic about pool size, number
of pages stored, and various counters for the reasons pages are rejected.
of pages stored, same-value filled pages and various counters for the reasons
pages are rejected.

37
Documentation/x86/x86_64/mm.txt
View file

@ -1,6 +1,4 @@
<previous description obsolete, deleted>
Virtual memory map with 4 level page tables:
0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
@ -14,13 +12,17 @@ ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
... unused hole ...
ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB)
... unused hole ...
vaddr_end for KASLR
fffffe0000000000 - fffffe7fffffffff (=39 bits) cpu_entry_area mapping
fffffe8000000000 - fffffeffffffffff (=39 bits) LDT remap for PTI
ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
... unused hole ...
ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
... unused hole ...
ffffffff80000000 - ffffffff9fffffff (=512 MB) kernel text mapping, from phys 0
ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space (variable)
ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
ffffffffa0000000 - [fixmap start] (~1526 MB) module mapping space (variable)
[fixmap start] - ffffffffff5fffff kernel-internal fixmap range
ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
Virtual memory map with 5 level page tables:
@ -29,26 +31,31 @@ Virtual memory map with 5 level page tables:
hole caused by [56:63] sign extension
ff00000000000000 - ff0fffffffffffff (=52 bits) guard hole, reserved for hypervisor
ff10000000000000 - ff8fffffffffffff (=55 bits) direct mapping of all phys. memory
ff90000000000000 - ff91ffffffffffff (=49 bits) hole
ff92000000000000 - ffd1ffffffffffff (=54 bits) vmalloc/ioremap space
ff90000000000000 - ff9fffffffffffff (=52 bits) LDT remap for PTI
ffa0000000000000 - ffd1ffffffffffff (=54 bits) vmalloc/ioremap space (12800 TB)
ffd2000000000000 - ffd3ffffffffffff (=49 bits) hole
ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB)
... unused hole ...
ffdf000000000000 - fffffc0000000000 (=53 bits) kasan shadow memory (8PB)
... unused hole ...
vaddr_end for KASLR
fffffe0000000000 - fffffe7fffffffff (=39 bits) cpu_entry_area mapping
... unused hole ...
ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
... unused hole ...
ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
... unused hole ...
ffffffff80000000 - ffffffff9fffffff (=512 MB) kernel text mapping, from phys 0
ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space
ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
ffffffffa0000000 - fffffffffeffffff (1520 MB) module mapping space
[fixmap start] - ffffffffff5fffff kernel-internal fixmap range
ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
Architecture defines a 64-bit virtual address. Implementations can support
less. Currently supported are 48- and 57-bit virtual addresses. Bits 63
through to the most-significant implemented bit are set to either all ones
or all zero. This causes hole between user space and kernel addresses.
through to the most-significant implemented bit are sign extended.
This causes hole between user space and kernel addresses if you interpret them
as unsigned.
The direct mapping covers all memory in the system up to the highest
memory address (this means in some cases it can also include PCI memory
@ -58,19 +65,15 @@ vmalloc space is lazily synchronized into the different PML4/PML5 pages of
the processes using the page fault handler, with init_top_pgt as
reference.
Current X86-64 implementations support up to 46 bits of address space (64 TB),
which is our current limit. This expands into MBZ space in the page tables.
We map EFI runtime services in the 'efi_pgd' PGD in a 64Gb large virtual
memory window (this size is arbitrary, it can be raised later if needed).
The mappings are not part of any other kernel PGD and are only available
during EFI runtime calls.
The module mapping space size changes based on the CONFIG requirements for the
following fixmap section.
Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
physical memory, vmalloc/ioremap space and virtual memory map are randomized.
Their order is preserved but their base will be offset early at boot time.
-Andi Kleen, Jul 2004
Be very careful vs. KASLR when changing anything here. The KASLR address
range must not overlap with anything except the KASAN shadow area, which is
correct as KASAN disables KASLR.

38
MAINTAINERS
View file

@ -2047,7 +2047,7 @@ F: arch/arm/boot/dts/uniphier*
F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
F: arch/arm/mm/cache-uniphier.c
F: arch/arm64/boot/dts/socionext/
F: arch/arm64/boot/dts/socionext/uniphier*
F: drivers/bus/uniphier-system-bus.c
F: drivers/clk/uniphier/
F: drivers/gpio/gpio-uniphier.c
@ -2621,24 +2621,22 @@ F: fs/bfs/
F: include/uapi/linux/bfs_fs.h
BLACKFIN ARCHITECTURE
M: Steven Miao <realmz6@gmail.com>
L: adi-buildroot-devel@lists.sourceforge.net (moderated for non-subscribers)
T: git git://git.code.sf.net/p/adi-linux/code
W: http://blackfin.uclinux.org
S: Supported
S: Orphan
F: arch/blackfin/
BLACKFIN EMAC DRIVER
L: adi-buildroot-devel@lists.sourceforge.net (moderated for non-subscribers)
W: http://blackfin.uclinux.org
S: Supported
S: Orphan
F: drivers/net/ethernet/adi/
BLACKFIN MEDIA DRIVER
M: Scott Jiang <scott.jiang.linux@gmail.com>
L: adi-buildroot-devel@lists.sourceforge.net (moderated for non-subscribers)
W: http://blackfin.uclinux.org/
S: Supported
S: Orphan
F: drivers/media/platform/blackfin/
F: drivers/media/i2c/adv7183*
F: drivers/media/i2c/vs6624*
@ -2646,25 +2644,25 @@ F: drivers/media/i2c/vs6624*
BLACKFIN RTC DRIVER
L: adi-buildroot-devel@lists.sourceforge.net (moderated for non-subscribers)
W: http://blackfin.uclinux.org
S: Supported
S: Orphan
F: drivers/rtc/rtc-bfin.c
BLACKFIN SDH DRIVER
L: adi-buildroot-devel@lists.sourceforge.net (moderated for non-subscribers)
W: http://blackfin.uclinux.org
S: Supported
S: Orphan
F: drivers/mmc/host/bfin_sdh.c
BLACKFIN SERIAL DRIVER
L: adi-buildroot-devel@lists.sourceforge.net (moderated for non-subscribers)
W: http://blackfin.uclinux.org
S: Supported
S: Orphan
F: drivers/tty/serial/bfin_uart.c
BLACKFIN WATCHDOG DRIVER
L: adi-buildroot-devel@lists.sourceforge.net (moderated for non-subscribers)
W: http://blackfin.uclinux.org
S: Supported
S: Orphan
F: drivers/watchdog/bfin_wdt.c
BLINKM RGB LED DRIVER
@ -5151,15 +5149,15 @@ F: sound/usb/misc/ua101.c
EFI TEST DRIVER
L: linux-efi@vger.kernel.org
M: Ivan Hu <ivan.hu@canonical.com>
M: Matt Fleming <matt@codeblueprint.co.uk>
M: Ard Biesheuvel <ard.biesheuvel@linaro.org>
S: Maintained
F: drivers/firmware/efi/test/
EFI VARIABLE FILESYSTEM
M: Matthew Garrett <matthew.garrett@nebula.com>
M: Jeremy Kerr <jk@ozlabs.org>
M: Matt Fleming <matt@codeblueprint.co.uk>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
M: Ard Biesheuvel <ard.biesheuvel@linaro.org>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
L: linux-efi@vger.kernel.org
S: Maintained
F: fs/efivarfs/
@ -5320,7 +5318,6 @@ S: Supported
F: security/integrity/evm/
EXTENSIBLE FIRMWARE INTERFACE (EFI)
M: Matt Fleming <matt@codeblueprint.co.uk>
M: Ard Biesheuvel <ard.biesheuvel@linaro.org>
L: linux-efi@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
@ -5431,7 +5428,7 @@ F: drivers/media/tuners/fc2580*
FCOE SUBSYSTEM (libfc, libfcoe, fcoe)
M: Johannes Thumshirn <jth@kernel.org>
L: fcoe-devel@open-fcoe.org
L: linux-scsi@vger.kernel.org
W: www.Open-FCoE.org
S: Supported
F: drivers/scsi/libfc/
@ -7767,6 +7764,7 @@ F: security/keys/
KGDB / KDB /debug_core
M: Jason Wessel <jason.wessel@windriver.com>
M: Daniel Thompson <daniel.thompson@linaro.org>
W: http://kgdb.wiki.kernel.org/
L: kgdb-bugreport@lists.sourceforge.net
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git
@ -12642,6 +12640,14 @@ S: Maintained
F: drivers/ssb/
F: include/linux/ssb/
SONY IMX274 SENSOR DRIVER
M: Leon Luo <leonl@leopardimaging.com>
L: linux-media@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/i2c/imx274.c
F: Documentation/devicetree/bindings/media/i2c/imx274.txt
SONY MEMORYSTICK CARD SUPPORT
M: Alex Dubov <oakad@yahoo.com>
W: http://tifmxx.berlios.de/
@ -13108,6 +13114,7 @@ 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
F: drivers/net/ethernet/synopsys/
@ -13483,6 +13490,7 @@ M: Mika Westerberg <mika.westerberg@linux.intel.com>
M: Yehezkel Bernat <yehezkel.bernat@intel.com>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git
S: Maintained
F: Documentation/admin-guide/thunderbolt.rst
F: drivers/thunderbolt/
F: include/linux/thunderbolt.h

5
Makefile
View file

@ -2,7 +2,7 @@
VERSION = 4
PATCHLEVEL = 15
SUBLEVEL = 0
EXTRAVERSION = -rc2
EXTRAVERSION = -rc6
NAME = Fearless Coyote
# *DOCUMENTATION*
@ -789,6 +789,9 @@ KBUILD_CFLAGS += $(call cc-disable-warning, pointer-sign)
# disable invalid "can't wrap" optimizations for signed / pointers
KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
# Make sure -fstack-check isn't enabled (like gentoo apparently did)
KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,)
# conserve stack if available
KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)

2
arch/alpha/include/uapi/asm/Kbuild
View file

@ -1,2 +1,4 @@
# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
generic-y += bpf_perf_event.h

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

@ -3,6 +3,7 @@ include include/uapi/asm-generic/Kbuild.asm
generic-y += auxvec.h
generic-y += bitsperlong.h
generic-y += bpf_perf_event.h
generic-y += errno.h
generic-y += fcntl.h
generic-y += ioctl.h

2
arch/arm/boot/dts/am33xx.dtsi
View file

@ -630,6 +630,7 @@
reg-names = "phy";
status = "disabled";
ti,ctrl_mod = <&usb_ctrl_mod>;
#phy-cells = <0>;
};
usb0: usb@47401000 {
@ -678,6 +679,7 @@
reg-names = "phy";
status = "disabled";
ti,ctrl_mod = <&usb_ctrl_mod>;
#phy-cells = <0>;
};
usb1: usb@47401800 {

6
arch/arm/boot/dts/am4372.dtsi
View file

@ -927,7 +927,8 @@
reg = <0x48038000 0x2000>,
<0x46000000 0x400000>;
reg-names = "mpu", "dat";
interrupts = <80>, <81>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "tx", "rx";
status = "disabled";
dmas = <&edma 8 2>,
@ -941,7 +942,8 @@
reg = <0x4803C000 0x2000>,
<0x46400000 0x400000>;
reg-names = "mpu", "dat";
interrupts = <82>, <83>;
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "tx", "rx";
status = "disabled";
dmas = <&edma 10 2>,

4
arch/arm/boot/dts/am437x-cm-t43.dts
View file

@ -301,8 +301,8 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins>;
dmas = <&edma 16
&edma 17>;
dmas = <&edma 16 0
&edma 17 0>;
dma-names = "tx0", "rx0";
flash: w25q64cvzpig@0 {

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