forked from Minki/linux
Merge 4.15-rc4 into usb-next
We want the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Greg Kroah-Hartman
commit
d9e3d899bc
@ -75,3 +75,4 @@ stable kernels.
|
|||||||
| Qualcomm Tech. | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
|
| Qualcomm Tech. | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
|
||||||
| Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
|
| Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
|
||||||
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
|
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
|
||||||
|
| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
|
||||||
|
|||||||
@ -898,6 +898,13 @@ controller implements weight and absolute bandwidth limit models for
|
|||||||
normal scheduling policy and absolute bandwidth allocation model for
|
normal scheduling policy and absolute bandwidth allocation model for
|
||||||
realtime scheduling policy.
|
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
|
CPU Interface Files
|
||||||
~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~
|
||||||
|
|||||||
@ -225,9 +225,9 @@ interrupts.
|
|||||||
|
|
||||||
The following control flow is implemented (simplified excerpt)::
|
The following control flow is implemented (simplified excerpt)::
|
||||||
|
|
||||||
:c:func:`desc->irq_data.chip->irq_mask_ack`;
|
desc->irq_data.chip->irq_mask_ack();
|
||||||
handle_irq_event(desc->action);
|
handle_irq_event(desc->action);
|
||||||
:c:func:`desc->irq_data.chip->irq_unmask`;
|
desc->irq_data.chip->irq_unmask();
|
||||||
|
|
||||||
|
|
||||||
Default Fast EOI IRQ flow handler
|
Default Fast EOI IRQ flow handler
|
||||||
@ -239,7 +239,7 @@ which only need an EOI at the end of the handler.
|
|||||||
The following control flow is implemented (simplified excerpt)::
|
The following control flow is implemented (simplified excerpt)::
|
||||||
|
|
||||||
handle_irq_event(desc->action);
|
handle_irq_event(desc->action);
|
||||||
:c:func:`desc->irq_data.chip->irq_eoi`;
|
desc->irq_data.chip->irq_eoi();
|
||||||
|
|
||||||
|
|
||||||
Default Edge IRQ flow handler
|
Default Edge IRQ flow handler
|
||||||
@ -251,15 +251,15 @@ interrupts.
|
|||||||
The following control flow is implemented (simplified excerpt)::
|
The following control flow is implemented (simplified excerpt)::
|
||||||
|
|
||||||
if (desc->status & running) {
|
if (desc->status & running) {
|
||||||
:c:func:`desc->irq_data.chip->irq_mask_ack`;
|
desc->irq_data.chip->irq_mask_ack();
|
||||||
desc->status |= pending | masked;
|
desc->status |= pending | masked;
|
||||||
return;
|
return;
|
||||||
}
|
}
|
||||||
:c:func:`desc->irq_data.chip->irq_ack`;
|
desc->irq_data.chip->irq_ack();
|
||||||
desc->status |= running;
|
desc->status |= running;
|
||||||
do {
|
do {
|
||||||
if (desc->status & masked)
|
if (desc->status & masked)
|
||||||
:c:func:`desc->irq_data.chip->irq_unmask`;
|
desc->irq_data.chip->irq_unmask();
|
||||||
desc->status &= ~pending;
|
desc->status &= ~pending;
|
||||||
handle_irq_event(desc->action);
|
handle_irq_event(desc->action);
|
||||||
} while (status & pending);
|
} while (status & pending);
|
||||||
@ -293,10 +293,10 @@ simplified version without locking.
|
|||||||
The following control flow is implemented (simplified excerpt)::
|
The following control flow is implemented (simplified excerpt)::
|
||||||
|
|
||||||
if (desc->irq_data.chip->irq_ack)
|
if (desc->irq_data.chip->irq_ack)
|
||||||
:c:func:`desc->irq_data.chip->irq_ack`;
|
desc->irq_data.chip->irq_ack();
|
||||||
handle_irq_event(desc->action);
|
handle_irq_event(desc->action);
|
||||||
if (desc->irq_data.chip->irq_eoi)
|
if (desc->irq_data.chip->irq_eoi)
|
||||||
:c:func:`desc->irq_data.chip->irq_eoi`;
|
desc->irq_data.chip->irq_eoi();
|
||||||
|
|
||||||
|
|
||||||
EOI Edge IRQ flow handler
|
EOI Edge IRQ flow handler
|
||||||
|
|||||||
@ -15,7 +15,7 @@ Required properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
ccn@0x2000000000 {
|
ccn@2000000000 {
|
||||||
compatible = "arm,ccn-504";
|
compatible = "arm,ccn-504";
|
||||||
reg = <0x20 0x00000000 0 0x1000000>;
|
reg = <0x20 0x00000000 0 0x1000000>;
|
||||||
interrupts = <0 181 4>;
|
interrupts = <0 181 4>;
|
||||||
|
|||||||
@ -49,7 +49,7 @@ An interrupt consumer on an SoC using crossbar will use:
|
|||||||
interrupts = <GIC_SPI request_number interrupt_level>
|
interrupts = <GIC_SPI request_number interrupt_level>
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
device_x@0x4a023000 {
|
device_x@4a023000 {
|
||||||
/* Crossbar 8 used */
|
/* Crossbar 8 used */
|
||||||
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
|
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
...
|
...
|
||||||
|
|||||||
@ -8,7 +8,7 @@ Required properties:
|
|||||||
- interrupts : Should contain MC General interrupt.
|
- interrupts : Should contain MC General interrupt.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
memory-controller@0x7000f000 {
|
memory-controller@7000f000 {
|
||||||
compatible = "nvidia,tegra20-mc";
|
compatible = "nvidia,tegra20-mc";
|
||||||
reg = <0x7000f000 0x024
|
reg = <0x7000f000 0x024
|
||||||
0x7000f03c 0x3c4>;
|
0x7000f03c 0x3c4>;
|
||||||
|
|||||||
@ -17,7 +17,7 @@ Optional properties:
|
|||||||
- clock-output-names : From common clock binding.
|
- clock-output-names : From common clock binding.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
clock@0xff000000 {
|
clock@ff000000 {
|
||||||
compatible = "adi,axi-clkgen";
|
compatible = "adi,axi-clkgen";
|
||||||
#clock-cells = <0>;
|
#clock-cells = <0>;
|
||||||
reg = <0xff000000 0x1000>;
|
reg = <0xff000000 0x1000>;
|
||||||
|
|||||||
@ -23,7 +23,7 @@ Example:
|
|||||||
clocks = <&clk_osc>;
|
clocks = <&clk_osc>;
|
||||||
};
|
};
|
||||||
|
|
||||||
aux: aux@0x7e215004 {
|
aux: aux@7e215004 {
|
||||||
compatible = "brcm,bcm2835-aux";
|
compatible = "brcm,bcm2835-aux";
|
||||||
#clock-cells = <1>;
|
#clock-cells = <1>;
|
||||||
reg = <0x7e215000 0x8>;
|
reg = <0x7e215000 0x8>;
|
||||||
|
|||||||
@ -24,7 +24,7 @@ tree sources.
|
|||||||
|
|
||||||
Example 1: An example of a clock controller node is listed below.
|
Example 1: An example of a clock controller node is listed below.
|
||||||
|
|
||||||
clock: clock-controller@0x10030000 {
|
clock: clock-controller@10030000 {
|
||||||
compatible = "samsung,exynos4210-clock";
|
compatible = "samsung,exynos4210-clock";
|
||||||
reg = <0x10030000 0x20000>;
|
reg = <0x10030000 0x20000>;
|
||||||
#clock-cells = <1>;
|
#clock-cells = <1>;
|
||||||
|
|||||||
@ -22,7 +22,7 @@ tree sources.
|
|||||||
|
|
||||||
Example 1: An example of a clock controller node is listed below.
|
Example 1: An example of a clock controller node is listed below.
|
||||||
|
|
||||||
clock: clock-controller@0x10010000 {
|
clock: clock-controller@10010000 {
|
||||||
compatible = "samsung,exynos5250-clock";
|
compatible = "samsung,exynos5250-clock";
|
||||||
reg = <0x10010000 0x30000>;
|
reg = <0x10010000 0x30000>;
|
||||||
#clock-cells = <1>;
|
#clock-cells = <1>;
|
||||||
|
|||||||
@ -30,7 +30,7 @@ Example 1: An example of a clock controller node is listed below.
|
|||||||
#clock-cells = <0>;
|
#clock-cells = <0>;
|
||||||
};
|
};
|
||||||
|
|
||||||
clock: clock-controller@0x10010000 {
|
clock: clock-controller@10010000 {
|
||||||
compatible = "samsung,exynos5410-clock";
|
compatible = "samsung,exynos5410-clock";
|
||||||
reg = <0x10010000 0x30000>;
|
reg = <0x10010000 0x30000>;
|
||||||
#clock-cells = <1>;
|
#clock-cells = <1>;
|
||||||
|
|||||||
@ -23,7 +23,7 @@ tree sources.
|
|||||||
|
|
||||||
Example 1: An example of a clock controller node is listed below.
|
Example 1: An example of a clock controller node is listed below.
|
||||||
|
|
||||||
clock: clock-controller@0x10010000 {
|
clock: clock-controller@10010000 {
|
||||||
compatible = "samsung,exynos5420-clock";
|
compatible = "samsung,exynos5420-clock";
|
||||||
reg = <0x10010000 0x30000>;
|
reg = <0x10010000 0x30000>;
|
||||||
#clock-cells = <1>;
|
#clock-cells = <1>;
|
||||||
|
|||||||
@ -21,7 +21,7 @@ tree sources.
|
|||||||
|
|
||||||
Example: An example of a clock controller node is listed below.
|
Example: An example of a clock controller node is listed below.
|
||||||
|
|
||||||
clock: clock-controller@0x10010000 {
|
clock: clock-controller@10010000 {
|
||||||
compatible = "samsung,exynos5440-clock";
|
compatible = "samsung,exynos5440-clock";
|
||||||
reg = <0x160000 0x10000>;
|
reg = <0x160000 0x10000>;
|
||||||
#clock-cells = <1>;
|
#clock-cells = <1>;
|
||||||
|
|||||||
@ -14,7 +14,7 @@ Required properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
pllctrl: pll-controller@0x02310000 {
|
pllctrl: pll-controller@02310000 {
|
||||||
compatible = "ti,keystone-pllctrl", "syscon";
|
compatible = "ti,keystone-pllctrl", "syscon";
|
||||||
reg = <0x02310000 0x200>;
|
reg = <0x02310000 0x200>;
|
||||||
};
|
};
|
||||||
|
|||||||
@ -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.
|
for the full list of zx296702 clock IDs.
|
||||||
|
|
||||||
|
|
||||||
topclk: topcrm@0x09800000 {
|
topclk: topcrm@09800000 {
|
||||||
compatible = "zte,zx296702-topcrm-clk";
|
compatible = "zte,zx296702-topcrm-clk";
|
||||||
reg = <0x09800000 0x1000>;
|
reg = <0x09800000 0x1000>;
|
||||||
#clock-cells = <1>;
|
#clock-cells = <1>;
|
||||||
};
|
};
|
||||||
|
|
||||||
uart0: serial@0x09405000 {
|
uart0: serial@09405000 {
|
||||||
compatible = "zte,zx296702-uart";
|
compatible = "zte,zx296702-uart";
|
||||||
reg = <0x09405000 0x1000>;
|
reg = <0x09405000 0x1000>;
|
||||||
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
|
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
|||||||
@ -456,7 +456,7 @@ System ON/OFF key driver
|
|||||||
Definition: this is phandle to the register map node.
|
Definition: this is phandle to the register map node.
|
||||||
|
|
||||||
EXAMPLE:
|
EXAMPLE:
|
||||||
snvs-pwrkey@0x020cc000 {
|
snvs-pwrkey@020cc000 {
|
||||||
compatible = "fsl,sec-v4.0-pwrkey";
|
compatible = "fsl,sec-v4.0-pwrkey";
|
||||||
regmap = <&snvs>;
|
regmap = <&snvs>;
|
||||||
interrupts = <0 4 0x4>
|
interrupts = <0 4 0x4>
|
||||||
@ -545,7 +545,7 @@ FULL EXAMPLE
|
|||||||
interrupts = <93 2>;
|
interrupts = <93 2>;
|
||||||
};
|
};
|
||||||
|
|
||||||
snvs-pwrkey@0x020cc000 {
|
snvs-pwrkey@020cc000 {
|
||||||
compatible = "fsl,sec-v4.0-pwrkey";
|
compatible = "fsl,sec-v4.0-pwrkey";
|
||||||
regmap = <&sec_mon>;
|
regmap = <&sec_mon>;
|
||||||
interrupts = <0 4 0x4>;
|
interrupts = <0 4 0x4>;
|
||||||
|
|||||||
@ -9,7 +9,7 @@ Required properties:
|
|||||||
- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
|
- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
dfi: dfi@0xff630000 {
|
dfi: dfi@ff630000 {
|
||||||
compatible = "rockchip,rk3399-dfi";
|
compatible = "rockchip,rk3399-dfi";
|
||||||
reg = <0x00 0xff630000 0x00 0x4000>;
|
reg = <0x00 0xff630000 0x00 0x4000>;
|
||||||
rockchip,pmu = <&pmugrf>;
|
rockchip,pmu = <&pmugrf>;
|
||||||
|
|||||||
@ -27,7 +27,7 @@ Optional properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
fb0: fb@0x00500000 {
|
fb0: fb@00500000 {
|
||||||
compatible = "atmel,at91sam9g45-lcdc";
|
compatible = "atmel,at91sam9g45-lcdc";
|
||||||
reg = <0x00500000 0x1000>;
|
reg = <0x00500000 0x1000>;
|
||||||
interrupts = <23 3 0>;
|
interrupts = <23 3 0>;
|
||||||
@ -41,7 +41,7 @@ Example:
|
|||||||
|
|
||||||
Example for fixed framebuffer memory:
|
Example for fixed framebuffer memory:
|
||||||
|
|
||||||
fb0: fb@0x00500000 {
|
fb0: fb@00500000 {
|
||||||
compatible = "atmel,at91sam9263-lcdc";
|
compatible = "atmel,at91sam9263-lcdc";
|
||||||
reg = <0x00700000 0x1000 0x70000000 0x200000>;
|
reg = <0x00700000 0x1000 0x70000000 0x200000>;
|
||||||
[...]
|
[...]
|
||||||
|
|||||||
@ -73,7 +73,7 @@ Hypervisor OS configuration:
|
|||||||
max-read-transactions = <31>;
|
max-read-transactions = <31>;
|
||||||
channel-reset-timeout-cycles = <0x500>;
|
channel-reset-timeout-cycles = <0x500>;
|
||||||
|
|
||||||
hidma_24: dma-controller@0x5c050000 {
|
hidma_24: dma-controller@5c050000 {
|
||||||
compatible = "qcom,hidma-1.0";
|
compatible = "qcom,hidma-1.0";
|
||||||
reg = <0 0x5c050000 0x0 0x1000>,
|
reg = <0 0x5c050000 0x0 0x1000>,
|
||||||
<0 0x5c0b0000 0x0 0x1000>;
|
<0 0x5c0b0000 0x0 0x1000>;
|
||||||
@ -85,7 +85,7 @@ Hypervisor OS configuration:
|
|||||||
|
|
||||||
Guest OS configuration:
|
Guest OS configuration:
|
||||||
|
|
||||||
hidma_24: dma-controller@0x5c050000 {
|
hidma_24: dma-controller@5c050000 {
|
||||||
compatible = "qcom,hidma-1.0";
|
compatible = "qcom,hidma-1.0";
|
||||||
reg = <0 0x5c050000 0x0 0x1000>,
|
reg = <0 0x5c050000 0x0 0x1000>,
|
||||||
<0 0x5c0b0000 0x0 0x1000>;
|
<0 0x5c0b0000 0x0 0x1000>;
|
||||||
|
|||||||
@ -13,7 +13,7 @@ Required properties:
|
|||||||
Example:
|
Example:
|
||||||
|
|
||||||
Controller:
|
Controller:
|
||||||
dma: dma-controller@0x09c00000{
|
dma: dma-controller@09c00000{
|
||||||
compatible = "zte,zx296702-dma";
|
compatible = "zte,zx296702-dma";
|
||||||
reg = <0x09c00000 0x1000>;
|
reg = <0x09c00000 0x1000>;
|
||||||
clocks = <&topclk ZX296702_DMA_ACLK>;
|
clocks = <&topclk ZX296702_DMA_ACLK>;
|
||||||
|
|||||||
@ -1,7 +1,12 @@
|
|||||||
EEPROMs (SPI) compatible with Atmel at25.
|
EEPROMs (SPI) compatible with Atmel at25.
|
||||||
|
|
||||||
Required properties:
|
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
|
- reg : chip select number
|
||||||
- spi-max-frequency : max spi frequency to use
|
- spi-max-frequency : max spi frequency to use
|
||||||
- pagesize : size of the eeprom page
|
- pagesize : size of the eeprom page
|
||||||
@ -13,7 +18,7 @@ Optional properties:
|
|||||||
- spi-cpol : SPI inverse clock polarity, as per spi-bus bindings.
|
- spi-cpol : SPI inverse clock polarity, as per spi-bus bindings.
|
||||||
- read-only : this parameter-less property disables writes to the eeprom
|
- 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":
|
"address-width", and "read-only":
|
||||||
- at25,byte-len : total eeprom size in bytes
|
- at25,byte-len : total eeprom size in bytes
|
||||||
- at25,addr-mode : addr-mode flags, as defined in include/linux/spi/eeprom.h
|
- 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.
|
Additional compatible properties are also allowed.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
at25@0 {
|
eeprom@0 {
|
||||||
compatible = "atmel,at25", "st,m95256";
|
compatible = "st,m95256", "atmel,at25";
|
||||||
reg = <0>
|
reg = <0>
|
||||||
spi-max-frequency = <5000000>;
|
spi-max-frequency = <5000000>;
|
||||||
spi-cpha;
|
spi-cpha;
|
||||||
|
|||||||
@ -30,7 +30,7 @@ Optional properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
gpio_altr: gpio@0xff200000 {
|
gpio_altr: gpio@ff200000 {
|
||||||
compatible = "altr,pio-1.0";
|
compatible = "altr,pio-1.0";
|
||||||
reg = <0xff200000 0x10>;
|
reg = <0xff200000 0x10>;
|
||||||
interrupts = <0 45 4>;
|
interrupts = <0 45 4>;
|
||||||
|
|||||||
@ -27,7 +27,7 @@ Required properties:
|
|||||||
ti,tca6424
|
ti,tca6424
|
||||||
ti,tca9539
|
ti,tca9539
|
||||||
ti,tca9554
|
ti,tca9554
|
||||||
onsemi,pca9654
|
onnn,pca9654
|
||||||
exar,xra1202
|
exar,xra1202
|
||||||
|
|
||||||
Optional properties:
|
Optional properties:
|
||||||
|
|||||||
@ -34,6 +34,10 @@ Required properties:
|
|||||||
|
|
||||||
- reg: I2C address
|
- reg: I2C address
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- smbus-timeout-disable: When set, the smbus timeout function will be disabled.
|
||||||
|
This is not supported on all chips.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
temp-sensor@1a {
|
temp-sensor@1a {
|
||||||
|
|||||||
@ -18,7 +18,7 @@ Optional properties:
|
|||||||
Example
|
Example
|
||||||
|
|
||||||
/ {
|
/ {
|
||||||
i2c4: i2c4@0x10054000 {
|
i2c4: i2c4@10054000 {
|
||||||
compatible = "ingenic,jz4780-i2c";
|
compatible = "ingenic,jz4780-i2c";
|
||||||
reg = <0x10054000 0x1000>;
|
reg = <0x10054000 0x1000>;
|
||||||
|
|
||||||
|
|||||||
@ -10,7 +10,7 @@ Required properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
hp03@0x77 {
|
hp03@77 {
|
||||||
compatible = "hoperf,hp03";
|
compatible = "hoperf,hp03";
|
||||||
reg = <0x77>;
|
reg = <0x77>;
|
||||||
xclr-gpio = <&portc 0 0x0>;
|
xclr-gpio = <&portc 0 0x0>;
|
||||||
|
|||||||
@ -15,7 +15,7 @@ Optional properties:
|
|||||||
Example:
|
Example:
|
||||||
|
|
||||||
i2c@80110000 {
|
i2c@80110000 {
|
||||||
bu21013_tp@0x5c {
|
bu21013_tp@5c {
|
||||||
compatible = "rohm,bu21013_tp";
|
compatible = "rohm,bu21013_tp";
|
||||||
reg = <0x5c>;
|
reg = <0x5c>;
|
||||||
touch-gpio = <&gpio2 20 0x4>;
|
touch-gpio = <&gpio2 20 0x4>;
|
||||||
|
|||||||
@ -155,7 +155,7 @@ Example:
|
|||||||
<0x0 0xe112f000 0 0x02000>,
|
<0x0 0xe112f000 0 0x02000>,
|
||||||
<0x0 0xe1140000 0 0x10000>,
|
<0x0 0xe1140000 0 0x10000>,
|
||||||
<0x0 0xe1160000 0 0x10000>;
|
<0x0 0xe1160000 0 0x10000>;
|
||||||
v2m0: v2m@0x8000 {
|
v2m0: v2m@8000 {
|
||||||
compatible = "arm,gic-v2m-frame";
|
compatible = "arm,gic-v2m-frame";
|
||||||
msi-controller;
|
msi-controller;
|
||||||
reg = <0x0 0x80000 0 0x1000>;
|
reg = <0x0 0x80000 0 0x1000>;
|
||||||
@ -163,7 +163,7 @@ Example:
|
|||||||
|
|
||||||
....
|
....
|
||||||
|
|
||||||
v2mN: v2m@0x9000 {
|
v2mN: v2m@9000 {
|
||||||
compatible = "arm,gic-v2m-frame";
|
compatible = "arm,gic-v2m-frame";
|
||||||
msi-controller;
|
msi-controller;
|
||||||
reg = <0x0 0x90000 0 0x1000>;
|
reg = <0x0 0x90000 0 0x1000>;
|
||||||
|
|||||||
@ -71,7 +71,7 @@ Example 2:
|
|||||||
* An interrupt generating device that is wired to a Meta external
|
* An interrupt generating device that is wired to a Meta external
|
||||||
* trigger block.
|
* trigger block.
|
||||||
*/
|
*/
|
||||||
uart1: uart@0x02004c00 {
|
uart1: uart@02004c00 {
|
||||||
// Interrupt source '5' that is level-sensitive.
|
// Interrupt source '5' that is level-sensitive.
|
||||||
// Note that there are only two cells as specified in the
|
// Note that there are only two cells as specified in the
|
||||||
// interrupt parent's '#interrupt-cells' property.
|
// interrupt parent's '#interrupt-cells' property.
|
||||||
|
|||||||
@ -51,7 +51,7 @@ Example 1:
|
|||||||
/*
|
/*
|
||||||
* TZ1090 PDC block
|
* TZ1090 PDC block
|
||||||
*/
|
*/
|
||||||
pdc: pdc@0x02006000 {
|
pdc: pdc@02006000 {
|
||||||
// This is an interrupt controller node.
|
// This is an interrupt controller node.
|
||||||
interrupt-controller;
|
interrupt-controller;
|
||||||
|
|
||||||
|
|||||||
@ -39,7 +39,7 @@ Example:
|
|||||||
|
|
||||||
The following is an example from the SPEAr320 SoC dtsi file.
|
The following is an example from the SPEAr320 SoC dtsi file.
|
||||||
|
|
||||||
shirq: interrupt-controller@0xb3000000 {
|
shirq: interrupt-controller@b3000000 {
|
||||||
compatible = "st,spear320-shirq";
|
compatible = "st,spear320-shirq";
|
||||||
reg = <0xb3000000 0x1000>;
|
reg = <0xb3000000 0x1000>;
|
||||||
interrupts = <28 29 30 1>;
|
interrupts = <28 29 30 1>;
|
||||||
|
|||||||
@ -14,7 +14,7 @@ Optional properties:
|
|||||||
depends on the interrupt controller parent.
|
depends on the interrupt controller parent.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
mbox_tx: mailbox@0x100 {
|
mbox_tx: mailbox@100 {
|
||||||
compatible = "altr,mailbox-1.0";
|
compatible = "altr,mailbox-1.0";
|
||||||
reg = <0x100 0x8>;
|
reg = <0x100 0x8>;
|
||||||
interrupt-parent = < &gic_0 >;
|
interrupt-parent = < &gic_0 >;
|
||||||
@ -22,7 +22,7 @@ Example:
|
|||||||
#mbox-cells = <1>;
|
#mbox-cells = <1>;
|
||||||
};
|
};
|
||||||
|
|
||||||
mbox_rx: mailbox@0x200 {
|
mbox_rx: mailbox@200 {
|
||||||
compatible = "altr,mailbox-1.0";
|
compatible = "altr,mailbox-1.0";
|
||||||
reg = <0x200 0x8>;
|
reg = <0x200 0x8>;
|
||||||
interrupt-parent = < &gic_0 >;
|
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.
|
used to give a name to the communication channel to be used by the client user.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
mclient0: mclient0@0x400 {
|
mclient0: mclient0@400 {
|
||||||
compatible = "client-1.0";
|
compatible = "client-1.0";
|
||||||
reg = <0x400 0x10>;
|
reg = <0x400 0x10>;
|
||||||
mbox-names = "mbox-tx", "mbox-rx";
|
mbox-names = "mbox-tx", "mbox-rx";
|
||||||
|
|||||||
@ -15,7 +15,7 @@ Optional properties:
|
|||||||
- brcm,use-bcm-hdr: present if a BCM header precedes each frame.
|
- brcm,use-bcm-hdr: present if a BCM header precedes each frame.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
pdc0: iproc-pdc0@0x612c0000 {
|
pdc0: iproc-pdc0@612c0000 {
|
||||||
compatible = "brcm,iproc-pdc-mbox";
|
compatible = "brcm,iproc-pdc-mbox";
|
||||||
reg = <0 0x612c0000 0 0x445>; /* PDC FS0 regs */
|
reg = <0 0x612c0000 0 0x445>; /* PDC FS0 regs */
|
||||||
interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
|
interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
|||||||
@ -17,7 +17,7 @@ Optional properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
gsc_0: gsc@0x13e00000 {
|
gsc_0: gsc@13e00000 {
|
||||||
compatible = "samsung,exynos5250-gsc";
|
compatible = "samsung,exynos5250-gsc";
|
||||||
reg = <0x13e00000 0x1000>;
|
reg = <0x13e00000 0x1000>;
|
||||||
interrupts = <0 85 0>;
|
interrupts = <0 85 0>;
|
||||||
|
|||||||
@ -68,7 +68,7 @@ vcodec_dec: vcodec@16000000 {
|
|||||||
"vdec_bus_clk_src";
|
"vdec_bus_clk_src";
|
||||||
};
|
};
|
||||||
|
|
||||||
vcodec_enc: vcodec@0x18002000 {
|
vcodec_enc: vcodec@18002000 {
|
||||||
compatible = "mediatek,mt8173-vcodec-enc";
|
compatible = "mediatek,mt8173-vcodec-enc";
|
||||||
reg = <0 0x18002000 0 0x1000>, /*VENC_SYS*/
|
reg = <0 0x18002000 0 0x1000>, /*VENC_SYS*/
|
||||||
<0 0x19002000 0 0x1000>; /*VENC_LT_SYS*/
|
<0 0x19002000 0 0x1000>; /*VENC_LT_SYS*/
|
||||||
|
|||||||
@ -44,7 +44,7 @@ Device node example
|
|||||||
vin0 = &vin0;
|
vin0 = &vin0;
|
||||||
};
|
};
|
||||||
|
|
||||||
vin0: vin@0xe6ef0000 {
|
vin0: vin@e6ef0000 {
|
||||||
compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
|
compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
|
||||||
clocks = <&mstp8_clks R8A7790_CLK_VIN0>;
|
clocks = <&mstp8_clks R8A7790_CLK_VIN0>;
|
||||||
reg = <0 0xe6ef0000 0 0x1000>;
|
reg = <0 0xe6ef0000 0 0x1000>;
|
||||||
|
|||||||
@ -138,7 +138,7 @@ Example:
|
|||||||
};
|
};
|
||||||
|
|
||||||
/* MIPI CSI-2 bus IF sensor */
|
/* MIPI CSI-2 bus IF sensor */
|
||||||
s5c73m3: sensor@0x1a {
|
s5c73m3: sensor@1a {
|
||||||
compatible = "samsung,s5c73m3";
|
compatible = "samsung,s5c73m3";
|
||||||
reg = <0x1a>;
|
reg = <0x1a>;
|
||||||
vddio-supply = <...>;
|
vddio-supply = <...>;
|
||||||
|
|||||||
@ -8,7 +8,7 @@ Bindings, specific for the sh_mobile_ceu_camera.c driver:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
ceu0: ceu@0xfe910000 {
|
ceu0: ceu@fe910000 {
|
||||||
compatible = "renesas,sh-mobile-ceu";
|
compatible = "renesas,sh-mobile-ceu";
|
||||||
reg = <0xfe910000 0xa0>;
|
reg = <0xfe910000 0xa0>;
|
||||||
interrupt-parent = <&intcs>;
|
interrupt-parent = <&intcs>;
|
||||||
|
|||||||
@ -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
|
'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.
|
pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
|
||||||
|
|
||||||
ceu0: ceu@0xfe910000 {
|
ceu0: ceu@fe910000 {
|
||||||
compatible = "renesas,sh-mobile-ceu";
|
compatible = "renesas,sh-mobile-ceu";
|
||||||
reg = <0xfe910000 0xa0>;
|
reg = <0xfe910000 0xa0>;
|
||||||
interrupts = <0x880>;
|
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";
|
compatible = "ovti,ov772x";
|
||||||
reg = <0x21>;
|
reg = <0x21>;
|
||||||
vddio-supply = <®ulator1>;
|
vddio-supply = <®ulator1>;
|
||||||
@ -219,7 +219,7 @@ pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
|
|||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
imx074: camera@0x1a {
|
imx074: camera@1a {
|
||||||
compatible = "sony,imx074";
|
compatible = "sony,imx074";
|
||||||
reg = <0x1a>;
|
reg = <0x1a>;
|
||||||
vddio-supply = <®ulator1>;
|
vddio-supply = <®ulator1>;
|
||||||
@ -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";
|
compatible = "renesas,sh-mobile-csi2";
|
||||||
reg = <0xffc90000 0x1000>;
|
reg = <0xffc90000 0x1000>;
|
||||||
interrupts = <0x17a0>;
|
interrupts = <0x17a0>;
|
||||||
|
|||||||
@ -46,7 +46,7 @@ Optional properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
emif1: emif@0x4c000000 {
|
emif1: emif@4c000000 {
|
||||||
compatible = "ti,emif-4d";
|
compatible = "ti,emif-4d";
|
||||||
ti,hwmods = "emif2";
|
ti,hwmods = "emif2";
|
||||||
phy-type = <1>;
|
phy-type = <1>;
|
||||||
|
|||||||
@ -13,7 +13,7 @@ Required properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
devctrl: device-state-control@0x02620000 {
|
devctrl: device-state-control@02620000 {
|
||||||
compatible = "ti,keystone-devctrl", "syscon";
|
compatible = "ti,keystone-devctrl", "syscon";
|
||||||
reg = <0x02620000 0x1000>;
|
reg = <0x02620000 0x1000>;
|
||||||
};
|
};
|
||||||
|
|||||||
@ -9,7 +9,7 @@ Required properties:
|
|||||||
- reg : Location and size of bounce buffer
|
- reg : Location and size of bounce buffer
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
smc@0x3404c000 {
|
smc@3404c000 {
|
||||||
compatible = "brcm,bcm11351-smc", "brcm,kona-smc";
|
compatible = "brcm,bcm11351-smc", "brcm,kona-smc";
|
||||||
reg = <0x3404c000 0x400>; //1 KiB in SRAM
|
reg = <0x3404c000 0x400>; //1 KiB in SRAM
|
||||||
};
|
};
|
||||||
|
|||||||
@ -12,7 +12,7 @@ Refer to clocks/clock-bindings.txt for generic clock consumer properties.
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
sdio2: sdio@0x3f1a0000 {
|
sdio2: sdio@3f1a0000 {
|
||||||
compatible = "brcm,kona-sdhci";
|
compatible = "brcm,kona-sdhci";
|
||||||
reg = <0x3f1a0000 0x10000>;
|
reg = <0x3f1a0000 0x10000>;
|
||||||
clocks = <&sdio3_clk>;
|
clocks = <&sdio3_clk>;
|
||||||
|
|||||||
@ -24,7 +24,7 @@ Optional properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
sdhci0: sdhci@0x18041000 {
|
sdhci0: sdhci@18041000 {
|
||||||
compatible = "brcm,sdhci-iproc-cygnus";
|
compatible = "brcm,sdhci-iproc-cygnus";
|
||||||
reg = <0x18041000 0x100>;
|
reg = <0x18041000 0x100>;
|
||||||
interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
|
interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
|||||||
@ -55,7 +55,7 @@ Examples:
|
|||||||
|
|
||||||
[hwmod populated DMA resources]
|
[hwmod populated DMA resources]
|
||||||
|
|
||||||
mmc1: mmc@0x4809c000 {
|
mmc1: mmc@4809c000 {
|
||||||
compatible = "ti,omap4-hsmmc";
|
compatible = "ti,omap4-hsmmc";
|
||||||
reg = <0x4809c000 0x400>;
|
reg = <0x4809c000 0x400>;
|
||||||
ti,hwmods = "mmc1";
|
ti,hwmods = "mmc1";
|
||||||
@ -67,7 +67,7 @@ Examples:
|
|||||||
|
|
||||||
[generic DMA request binding]
|
[generic DMA request binding]
|
||||||
|
|
||||||
mmc1: mmc@0x4809c000 {
|
mmc1: mmc@4809c000 {
|
||||||
compatible = "ti,omap4-hsmmc";
|
compatible = "ti,omap4-hsmmc";
|
||||||
reg = <0x4809c000 0x400>;
|
reg = <0x4809c000 0x400>;
|
||||||
ti,hwmods = "mmc1";
|
ti,hwmods = "mmc1";
|
||||||
|
|||||||
@ -82,15 +82,15 @@ gpmc: gpmc@6e000000 {
|
|||||||
label = "bootloader-nor";
|
label = "bootloader-nor";
|
||||||
reg = <0 0x40000>;
|
reg = <0 0x40000>;
|
||||||
};
|
};
|
||||||
partition@0x40000 {
|
partition@40000 {
|
||||||
label = "params-nor";
|
label = "params-nor";
|
||||||
reg = <0x40000 0x40000>;
|
reg = <0x40000 0x40000>;
|
||||||
};
|
};
|
||||||
partition@0x80000 {
|
partition@80000 {
|
||||||
label = "kernel-nor";
|
label = "kernel-nor";
|
||||||
reg = <0x80000 0x200000>;
|
reg = <0x80000 0x200000>;
|
||||||
};
|
};
|
||||||
partition@0x280000 {
|
partition@280000 {
|
||||||
label = "filesystem-nor";
|
label = "filesystem-nor";
|
||||||
reg = <0x240000 0x7d80000>;
|
reg = <0x240000 0x7d80000>;
|
||||||
};
|
};
|
||||||
|
|||||||
@ -131,7 +131,7 @@ Example:
|
|||||||
read-only;
|
read-only;
|
||||||
reg = <0x00000000 0x00400000>;
|
reg = <0x00000000 0x00400000>;
|
||||||
};
|
};
|
||||||
android@0x00400000 {
|
android@00400000 {
|
||||||
label = "android";
|
label = "android";
|
||||||
reg = <0x00400000 0x12c00000>;
|
reg = <0x00400000 0x12c00000>;
|
||||||
};
|
};
|
||||||
|
|||||||
@ -52,7 +52,7 @@ Optional properties:
|
|||||||
|
|
||||||
Example:
|
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";
|
compatible = "altr,tse-msgdma-1.0";
|
||||||
reg = <0x00000001 0x00000000 0x00000400>,
|
reg = <0x00000001 0x00000000 0x00000400>,
|
||||||
<0x00000001 0x00000460 0x00000020>,
|
<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";
|
compatible = "altr,tse-msgdma-1.0";
|
||||||
reg = <0x00000001 0x00001000 0x00000400>,
|
reg = <0x00000001 0x00001000 0x00000400>,
|
||||||
<0x00000001 0x00001460 0x00000020>,
|
<0x00000001 0x00001460 0x00000020>,
|
||||||
|
|||||||
@ -18,7 +18,7 @@ Example :
|
|||||||
This example shows these optional properties, plus other properties
|
This example shows these optional properties, plus other properties
|
||||||
required for the TI Davinci MDIO driver.
|
required for the TI Davinci MDIO driver.
|
||||||
|
|
||||||
davinci_mdio: ethernet@0x5c030000 {
|
davinci_mdio: ethernet@5c030000 {
|
||||||
compatible = "ti,davinci_mdio";
|
compatible = "ti,davinci_mdio";
|
||||||
reg = <0x5c030000 0x1000>;
|
reg = <0x5c030000 0x1000>;
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
|
|||||||
@ -28,7 +28,7 @@ Required properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
gmii_to_sgmii_converter: phy@0x100000240 {
|
gmii_to_sgmii_converter: phy@100000240 {
|
||||||
compatible = "altr,gmii-to-sgmii-2.0";
|
compatible = "altr,gmii-to-sgmii-2.0";
|
||||||
reg = <0x00000001 0x00000240 0x00000008>,
|
reg = <0x00000001 0x00000240 0x00000008>,
|
||||||
<0x00000001 0x00000200 0x00000040>;
|
<0x00000001 0x00000200 0x00000040>;
|
||||||
|
|||||||
@ -36,7 +36,7 @@ Optional properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
cpu@0x0 {
|
cpu@0 {
|
||||||
device_type = "cpu";
|
device_type = "cpu";
|
||||||
compatible = "altr,nios2-1.0";
|
compatible = "altr,nios2-1.0";
|
||||||
reg = <0>;
|
reg = <0>;
|
||||||
|
|||||||
@ -25,7 +25,7 @@ Optional properties:
|
|||||||
- bus-range: PCI bus numbers covered
|
- bus-range: PCI bus numbers covered
|
||||||
|
|
||||||
Example
|
Example
|
||||||
pcie_0: pcie@0xc00000000 {
|
pcie_0: pcie@c00000000 {
|
||||||
compatible = "altr,pcie-root-port-1.0";
|
compatible = "altr,pcie-root-port-1.0";
|
||||||
reg = <0xc0000000 0x20000000>,
|
reg = <0xc0000000 0x20000000>,
|
||||||
<0xff220000 0x00004000>;
|
<0xff220000 0x00004000>;
|
||||||
|
|||||||
@ -52,7 +52,7 @@ Additional required properties for imx7d-pcie:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
pcie@0x01000000 {
|
pcie@01000000 {
|
||||||
compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
|
compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
|
||||||
reg = <0x01ffc000 0x04000>,
|
reg = <0x01ffc000 0x04000>,
|
||||||
<0x01f00000 0x80000>;
|
<0x01f00000 0x80000>;
|
||||||
|
|||||||
@ -21,7 +21,7 @@ Optional properties:
|
|||||||
- dma-coherent: Present if DMA operations are coherent.
|
- dma-coherent: Present if DMA operations are coherent.
|
||||||
|
|
||||||
Hip05 Example (note that Hip06 is the same except compatible):
|
Hip05 Example (note that Hip06 is the same except compatible):
|
||||||
pcie@0xb0080000 {
|
pcie@b0080000 {
|
||||||
compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
|
compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
|
||||||
reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
|
reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
|
||||||
reg-names = "rc_dbi", "config";
|
reg-names = "rc_dbi", "config";
|
||||||
|
|||||||
@ -45,7 +45,7 @@ Optional properties:
|
|||||||
- usb3_vbus-supply : regulator phandle for controller usb3 vbus
|
- usb3_vbus-supply : regulator phandle for controller usb3 vbus
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
usbphy: phy@0x01c13400 {
|
usbphy: phy@01c13400 {
|
||||||
#phy-cells = <1>;
|
#phy-cells = <1>;
|
||||||
compatible = "allwinner,sun4i-a10-usb-phy";
|
compatible = "allwinner,sun4i-a10-usb-phy";
|
||||||
/* phy base regs, phy1 pmu reg, phy2 pmu reg */
|
/* phy base regs, phy1 pmu reg, phy2 pmu reg */
|
||||||
|
|||||||
@ -25,7 +25,7 @@ Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
|
|||||||
|
|
||||||
For example:
|
For example:
|
||||||
|
|
||||||
pinmux: pinmux@0x0301d0c8 {
|
pinmux: pinmux@0301d0c8 {
|
||||||
compatible = "brcm,cygnus-pinmux";
|
compatible = "brcm,cygnus-pinmux";
|
||||||
reg = <0x0301d0c8 0x1b0>;
|
reg = <0x0301d0c8 0x1b0>;
|
||||||
|
|
||||||
|
|||||||
@ -96,14 +96,14 @@ For example, pinctrl might have subnodes like the following:
|
|||||||
|
|
||||||
For a specific board, if it wants to use sd1,
|
For a specific board, if it wants to use sd1,
|
||||||
it can add the following to its board-specific .dts file.
|
it can add the following to its board-specific .dts file.
|
||||||
sd1: sd@0x12340000 {
|
sd1: sd@12340000 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&sd1_pmx0>;
|
pinctrl-0 = <&sd1_pmx0>;
|
||||||
}
|
}
|
||||||
|
|
||||||
or
|
or
|
||||||
|
|
||||||
sd1: sd@0x12340000 {
|
sd1: sd@12340000 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&sd1_pmx1>;
|
pinctrl-0 = <&sd1_pmx1>;
|
||||||
}
|
}
|
||||||
|
|||||||
@ -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,
|
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.
|
it can add the following to its board-specific .dts file.
|
||||||
uart2: uart@0xb0070000 {
|
uart2: uart@b0070000 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&uart2_noflow_pins_a>;
|
pinctrl-0 = <&uart2_noflow_pins_a>;
|
||||||
}
|
}
|
||||||
|
|||||||
@ -136,7 +136,7 @@ Example for rk3188:
|
|||||||
#size-cells = <1>;
|
#size-cells = <1>;
|
||||||
ranges;
|
ranges;
|
||||||
|
|
||||||
gpio0: gpio0@0x2000a000 {
|
gpio0: gpio0@2000a000 {
|
||||||
compatible = "rockchip,rk3188-gpio-bank0";
|
compatible = "rockchip,rk3188-gpio-bank0";
|
||||||
reg = <0x2000a000 0x100>;
|
reg = <0x2000a000 0x100>;
|
||||||
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
|
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
@ -149,7 +149,7 @@ Example for rk3188:
|
|||||||
#interrupt-cells = <2>;
|
#interrupt-cells = <2>;
|
||||||
};
|
};
|
||||||
|
|
||||||
gpio1: gpio1@0x2003c000 {
|
gpio1: gpio1@2003c000 {
|
||||||
compatible = "rockchip,gpio-bank";
|
compatible = "rockchip,gpio-bank";
|
||||||
reg = <0x2003c000 0x100>;
|
reg = <0x2003c000 0x100>;
|
||||||
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
|
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
|||||||
@ -107,7 +107,7 @@ regulators (twl_reg1 and twl_reg2),
|
|||||||
...
|
...
|
||||||
};
|
};
|
||||||
|
|
||||||
mmc: mmc@0x0 {
|
mmc: mmc@0 {
|
||||||
...
|
...
|
||||||
...
|
...
|
||||||
vmmc-supply = <&twl_reg1>;
|
vmmc-supply = <&twl_reg1>;
|
||||||
|
|||||||
@ -12,7 +12,7 @@ Optional properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
uart@0x4000c400 {
|
uart@4000c400 {
|
||||||
compatible = "energymicro,efm32-uart";
|
compatible = "energymicro,efm32-uart";
|
||||||
reg = <0x4000c400 0x400>;
|
reg = <0x4000c400 0x400>;
|
||||||
interrupts = <15>;
|
interrupts = <15>;
|
||||||
|
|||||||
@ -14,7 +14,7 @@ Required properties:
|
|||||||
|
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
ps20: ps2@0x01c2a000 {
|
ps20: ps2@01c2a000 {
|
||||||
compatible = "allwinner,sun4i-a10-ps2";
|
compatible = "allwinner,sun4i-a10-ps2";
|
||||||
reg = <0x01c2a000 0x400>;
|
reg = <0x01c2a000 0x400>;
|
||||||
interrupts = <0 62 4>;
|
interrupts = <0 62 4>;
|
||||||
|
|||||||
@ -220,7 +220,7 @@ qmss: qmss@2a40000 {
|
|||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
#size-cells = <1>;
|
#size-cells = <1>;
|
||||||
ranges;
|
ranges;
|
||||||
pdsp0@0x2a10000 {
|
pdsp0@2a10000 {
|
||||||
reg = <0x2a10000 0x1000>,
|
reg = <0x2a10000 0x1000>,
|
||||||
<0x2a0f000 0x100>,
|
<0x2a0f000 0x100>,
|
||||||
<0x2a0c000 0x3c8>,
|
<0x2a0c000 0x3c8>,
|
||||||
|
|||||||
@ -21,7 +21,7 @@ please check:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
i2s: i2s@0x77600000 {
|
i2s: i2s@77600000 {
|
||||||
compatible = "adi,axi-i2s-1.00.a";
|
compatible = "adi,axi-i2s-1.00.a";
|
||||||
reg = <0x77600000 0x1000>;
|
reg = <0x77600000 0x1000>;
|
||||||
clocks = <&clk 15>, <&audio_clock>;
|
clocks = <&clk 15>, <&audio_clock>;
|
||||||
|
|||||||
@ -20,7 +20,7 @@ please check:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
spdif: spdif@0x77400000 {
|
spdif: spdif@77400000 {
|
||||||
compatible = "adi,axi-spdif-tx-1.00.a";
|
compatible = "adi,axi-spdif-tx-1.00.a";
|
||||||
reg = <0x77600000 0x1000>;
|
reg = <0x77600000 0x1000>;
|
||||||
clocks = <&clk 15>, <&audio_clock>;
|
clocks = <&clk 15>, <&audio_clock>;
|
||||||
|
|||||||
@ -20,7 +20,7 @@ Optional properties:
|
|||||||
Example:
|
Example:
|
||||||
|
|
||||||
&i2c {
|
&i2c {
|
||||||
ak4613: ak4613@0x10 {
|
ak4613: ak4613@10 {
|
||||||
compatible = "asahi-kasei,ak4613";
|
compatible = "asahi-kasei,ak4613";
|
||||||
reg = <0x10>;
|
reg = <0x10>;
|
||||||
};
|
};
|
||||||
|
|||||||
@ -17,7 +17,7 @@ Optional properties:
|
|||||||
Example 1:
|
Example 1:
|
||||||
|
|
||||||
&i2c {
|
&i2c {
|
||||||
ak4648: ak4648@0x12 {
|
ak4648: ak4648@12 {
|
||||||
compatible = "asahi-kasei,ak4642";
|
compatible = "asahi-kasei,ak4642";
|
||||||
reg = <0x12>;
|
reg = <0x12>;
|
||||||
};
|
};
|
||||||
|
|||||||
@ -10,7 +10,7 @@ Required properties:
|
|||||||
Example:
|
Example:
|
||||||
|
|
||||||
&i2c {
|
&i2c {
|
||||||
max98371: max98371@0x31 {
|
max98371: max98371@31 {
|
||||||
compatible = "maxim,max98371";
|
compatible = "maxim,max98371";
|
||||||
reg = <0x31>;
|
reg = <0x31>;
|
||||||
};
|
};
|
||||||
|
|||||||
@ -10,7 +10,7 @@ Required properties:
|
|||||||
Example:
|
Example:
|
||||||
|
|
||||||
&i2c {
|
&i2c {
|
||||||
max9867: max9867@0x18 {
|
max9867: max9867@18 {
|
||||||
compatible = "maxim,max9867";
|
compatible = "maxim,max9867";
|
||||||
reg = <0x18>;
|
reg = <0x18>;
|
||||||
};
|
};
|
||||||
|
|||||||
@ -20,7 +20,7 @@ Required properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
sh_fsi2: sh_fsi2@0xec230000 {
|
sh_fsi2: sh_fsi2@ec230000 {
|
||||||
compatible = "renesas,sh_fsi2";
|
compatible = "renesas,sh_fsi2";
|
||||||
reg = <0xec230000 0x400>;
|
reg = <0xec230000 0x400>;
|
||||||
interrupts = <0 146 0x4>;
|
interrupts = <0 146 0x4>;
|
||||||
|
|||||||
@ -33,7 +33,7 @@ Required properties on RK3288:
|
|||||||
|
|
||||||
Example for the rk3188 SPDIF controller:
|
Example for the rk3188 SPDIF controller:
|
||||||
|
|
||||||
spdif: spdif@0x1011e000 {
|
spdif: spdif@1011e000 {
|
||||||
compatible = "rockchip,rk3188-spdif", "rockchip,rk3066-spdif";
|
compatible = "rockchip,rk3188-spdif", "rockchip,rk3066-spdif";
|
||||||
reg = <0x1011e000 0x2000>;
|
reg = <0x1011e000 0x2000>;
|
||||||
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
|
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
|||||||
@ -51,7 +51,7 @@ Optional properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
sti_uni_player1: sti-uni-player@0x8D81000 {
|
sti_uni_player1: sti-uni-player@8D81000 {
|
||||||
compatible = "st,stih407-uni-player-hdmi";
|
compatible = "st,stih407-uni-player-hdmi";
|
||||||
#sound-dai-cells = <0>;
|
#sound-dai-cells = <0>;
|
||||||
st,syscfg = <&syscfg_core>;
|
st,syscfg = <&syscfg_core>;
|
||||||
@ -63,7 +63,7 @@ Example:
|
|||||||
st,tdm-mode = <1>;
|
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";
|
compatible = "st,stih407-uni-player-pcm-out";
|
||||||
#sound-dai-cells = <0>;
|
#sound-dai-cells = <0>;
|
||||||
st,syscfg = <&syscfg_core>;
|
st,syscfg = <&syscfg_core>;
|
||||||
@ -74,7 +74,7 @@ Example:
|
|||||||
dma-names = "tx";
|
dma-names = "tx";
|
||||||
};
|
};
|
||||||
|
|
||||||
sti_uni_player3: sti-uni-player@0x8D85000 {
|
sti_uni_player3: sti-uni-player@8D85000 {
|
||||||
compatible = "st,stih407-uni-player-spdif";
|
compatible = "st,stih407-uni-player-spdif";
|
||||||
#sound-dai-cells = <0>;
|
#sound-dai-cells = <0>;
|
||||||
st,syscfg = <&syscfg_core>;
|
st,syscfg = <&syscfg_core>;
|
||||||
@ -85,7 +85,7 @@ Example:
|
|||||||
dma-names = "tx";
|
dma-names = "tx";
|
||||||
};
|
};
|
||||||
|
|
||||||
sti_uni_reader1: sti-uni-reader@0x8D84000 {
|
sti_uni_reader1: sti-uni-reader@8D84000 {
|
||||||
compatible = "st,stih407-uni-reader-hdmi";
|
compatible = "st,stih407-uni-reader-hdmi";
|
||||||
#sound-dai-cells = <0>;
|
#sound-dai-cells = <0>;
|
||||||
st,syscfg = <&syscfg_core>;
|
st,syscfg = <&syscfg_core>;
|
||||||
|
|||||||
@ -19,7 +19,7 @@ Recommended properties :
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
spi1: spi@0x4000c400 { /* USART1 */
|
spi1: spi@4000c400 { /* USART1 */
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
#size-cells = <0>;
|
#size-cells = <0>;
|
||||||
compatible = "energymicro,efm32-spi";
|
compatible = "energymicro,efm32-spi";
|
||||||
|
|||||||
@ -239,7 +239,7 @@ cpus {
|
|||||||
* A simple fan controller which supports 10 speeds of operation
|
* A simple fan controller which supports 10 speeds of operation
|
||||||
* (represented as 0-9).
|
* (represented as 0-9).
|
||||||
*/
|
*/
|
||||||
fan0: fan@0x48 {
|
fan0: fan@48 {
|
||||||
...
|
...
|
||||||
cooling-min-level = <0>;
|
cooling-min-level = <0>;
|
||||||
cooling-max-level = <9>;
|
cooling-max-level = <9>;
|
||||||
@ -252,7 +252,7 @@ ocp {
|
|||||||
/*
|
/*
|
||||||
* A simple IC with a single bandgap temperature sensor.
|
* A simple IC with a single bandgap temperature sensor.
|
||||||
*/
|
*/
|
||||||
bandgap0: bandgap@0x0000ED00 {
|
bandgap0: bandgap@0000ED00 {
|
||||||
...
|
...
|
||||||
#thermal-sensor-cells = <0>;
|
#thermal-sensor-cells = <0>;
|
||||||
};
|
};
|
||||||
@ -330,7 +330,7 @@ ocp {
|
|||||||
/*
|
/*
|
||||||
* A simple IC with several bandgap temperature sensors.
|
* A simple IC with several bandgap temperature sensors.
|
||||||
*/
|
*/
|
||||||
bandgap0: bandgap@0x0000ED00 {
|
bandgap0: bandgap@0000ED00 {
|
||||||
...
|
...
|
||||||
#thermal-sensor-cells = <1>;
|
#thermal-sensor-cells = <1>;
|
||||||
};
|
};
|
||||||
@ -447,7 +447,7 @@ one thermal zone.
|
|||||||
/*
|
/*
|
||||||
* A simple IC with a single temperature sensor.
|
* A simple IC with a single temperature sensor.
|
||||||
*/
|
*/
|
||||||
adc: sensor@0x49 {
|
adc: sensor@49 {
|
||||||
...
|
...
|
||||||
#thermal-sensor-cells = <0>;
|
#thermal-sensor-cells = <0>;
|
||||||
};
|
};
|
||||||
@ -458,7 +458,7 @@ ocp {
|
|||||||
/*
|
/*
|
||||||
* A simple IC with a single bandgap temperature sensor.
|
* A simple IC with a single bandgap temperature sensor.
|
||||||
*/
|
*/
|
||||||
bandgap0: bandgap@0x0000ED00 {
|
bandgap0: bandgap@0000ED00 {
|
||||||
...
|
...
|
||||||
#thermal-sensor-cells = <0>;
|
#thermal-sensor-cells = <0>;
|
||||||
};
|
};
|
||||||
@ -516,7 +516,7 @@ with many sensors and many cooling devices.
|
|||||||
/*
|
/*
|
||||||
* An IC with several temperature sensor.
|
* An IC with several temperature sensor.
|
||||||
*/
|
*/
|
||||||
adc_dummy: sensor@0x50 {
|
adc_dummy: sensor@50 {
|
||||||
...
|
...
|
||||||
#thermal-sensor-cells = <1>; /* sensor internal ID */
|
#thermal-sensor-cells = <1>; /* sensor internal ID */
|
||||||
};
|
};
|
||||||
|
|||||||
@ -32,7 +32,7 @@ Optional properties:
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
ufsphy1: ufsphy@0xfc597000 {
|
ufsphy1: ufsphy@fc597000 {
|
||||||
compatible = "qcom,ufs-phy-qmp-20nm";
|
compatible = "qcom,ufs-phy-qmp-20nm";
|
||||||
reg = <0xfc597000 0x800>;
|
reg = <0xfc597000 0x800>;
|
||||||
reg-names = "phy_mem";
|
reg-names = "phy_mem";
|
||||||
@ -53,7 +53,7 @@ Example:
|
|||||||
<&clock_gcc clk_gcc_ufs_rx_cfg_clk>;
|
<&clock_gcc clk_gcc_ufs_rx_cfg_clk>;
|
||||||
};
|
};
|
||||||
|
|
||||||
ufshc@0xfc598000 {
|
ufshc@fc598000 {
|
||||||
...
|
...
|
||||||
phys = <&ufsphy1>;
|
phys = <&ufsphy1>;
|
||||||
phy-names = "ufsphy";
|
phy-names = "ufsphy";
|
||||||
|
|||||||
@ -46,7 +46,7 @@ Note: If above properties are not defined it can be assumed that the supply
|
|||||||
regulators or clocks are always on.
|
regulators or clocks are always on.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
ufshc@0xfc598000 {
|
ufshc@fc598000 {
|
||||||
compatible = "jedec,ufs-1.1";
|
compatible = "jedec,ufs-1.1";
|
||||||
reg = <0xfc598000 0x800>;
|
reg = <0xfc598000 0x800>;
|
||||||
interrupts = <0 28 0>;
|
interrupts = <0 28 0>;
|
||||||
|
|||||||
@ -95,6 +95,7 @@ usb: usb@47400000 {
|
|||||||
reg = <0x47401300 0x100>;
|
reg = <0x47401300 0x100>;
|
||||||
reg-names = "phy";
|
reg-names = "phy";
|
||||||
ti,ctrl_mod = <&ctrl_mod>;
|
ti,ctrl_mod = <&ctrl_mod>;
|
||||||
|
#phy-cells = <0>;
|
||||||
};
|
};
|
||||||
|
|
||||||
usb0: usb@47401000 {
|
usb0: usb@47401000 {
|
||||||
@ -141,6 +142,7 @@ usb: usb@47400000 {
|
|||||||
reg = <0x47401b00 0x100>;
|
reg = <0x47401b00 0x100>;
|
||||||
reg-names = "phy";
|
reg-names = "phy";
|
||||||
ti,ctrl_mod = <&ctrl_mod>;
|
ti,ctrl_mod = <&ctrl_mod>;
|
||||||
|
#phy-cells = <0>;
|
||||||
};
|
};
|
||||||
|
|
||||||
usb1: usb@47401800 {
|
usb1: usb@47401800 {
|
||||||
|
|||||||
@ -22,7 +22,7 @@ See: Documentation/devicetree/bindings/reset/reset.txt
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
ehci1: usb@0xfe203e00 {
|
ehci1: usb@fe203e00 {
|
||||||
compatible = "st,st-ehci-300x";
|
compatible = "st,st-ehci-300x";
|
||||||
reg = <0xfe203e00 0x100>;
|
reg = <0xfe203e00 0x100>;
|
||||||
interrupts = <GIC_SPI 148 IRQ_TYPE_NONE>;
|
interrupts = <GIC_SPI 148 IRQ_TYPE_NONE>;
|
||||||
|
|||||||
@ -20,7 +20,7 @@ See: Documentation/devicetree/bindings/reset/reset.txt
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
ohci0: usb@0xfe1ffc00 {
|
ohci0: usb@fe1ffc00 {
|
||||||
compatible = "st,st-ohci-300x";
|
compatible = "st,st-ohci-300x";
|
||||||
reg = <0xfe1ffc00 0x100>;
|
reg = <0xfe1ffc00 0x100>;
|
||||||
interrupts = <GIC_SPI 149 IRQ_TYPE_NONE>;
|
interrupts = <GIC_SPI 149 IRQ_TYPE_NONE>;
|
||||||
|
|||||||
@ -6,7 +6,7 @@ reg: Register address and length for watchdog registers
|
|||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
watchdog: jz4740-watchdog@0x10002000 {
|
watchdog: jz4740-watchdog@10002000 {
|
||||||
compatible = "ingenic,jz4740-watchdog";
|
compatible = "ingenic,jz4740-watchdog";
|
||||||
reg = <0x10002000 0x100>;
|
reg = <0x10002000 0x100>;
|
||||||
};
|
};
|
||||||
|
|||||||
@ -185,7 +185,7 @@ The details of these operations are:
|
|||||||
void dma_async_issue_pending(struct dma_chan *chan);
|
void dma_async_issue_pending(struct dma_chan *chan);
|
||||||
|
|
||||||
Further APIs:
|
Further APIs:
|
||||||
------------
|
-------------
|
||||||
|
|
||||||
1. Terminate APIs
|
1. Terminate APIs
|
||||||
|
|
||||||
|
|||||||
@ -25,9 +25,6 @@ PCI Support Library
|
|||||||
.. kernel-doc:: drivers/pci/irq.c
|
.. kernel-doc:: drivers/pci/irq.c
|
||||||
:export:
|
:export:
|
||||||
|
|
||||||
.. kernel-doc:: drivers/pci/htirq.c
|
|
||||||
:export:
|
|
||||||
|
|
||||||
.. kernel-doc:: drivers/pci/probe.c
|
.. kernel-doc:: drivers/pci/probe.c
|
||||||
:export:
|
:export:
|
||||||
|
|
||||||
|
|||||||
@ -156,6 +156,40 @@ handle it in two different ways:
|
|||||||
root of the overlay. Finally the directory is moved to the new
|
root of the overlay. Finally the directory is moved to the new
|
||||||
location.
|
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
|
Non-directories
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
|
|||||||
@ -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
30
Documentation/media/dvb-drivers/frontends.rst
Normal 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
|
||||||
|
|
||||||
@ -41,4 +41,5 @@ For more details see the file COPYING in the source distribution of Linux.
|
|||||||
technisat
|
technisat
|
||||||
ttusb-dec
|
ttusb-dec
|
||||||
udev
|
udev
|
||||||
|
frontends
|
||||||
contributors
|
contributors
|
||||||
|
|||||||
@ -5,7 +5,6 @@ How to get printk format specifiers right
|
|||||||
:Author: Randy Dunlap <rdunlap@infradead.org>
|
:Author: Randy Dunlap <rdunlap@infradead.org>
|
||||||
:Author: Andrew Murray <amurray@mpc-data.co.uk>
|
:Author: Andrew Murray <amurray@mpc-data.co.uk>
|
||||||
|
|
||||||
|
|
||||||
Integer types
|
Integer types
|
||||||
=============
|
=============
|
||||||
|
|
||||||
@ -45,6 +44,18 @@ return from vsnprintf.
|
|||||||
Raw pointer value SHOULD be printed with %p. The kernel supports
|
Raw pointer value SHOULD be printed with %p. The kernel supports
|
||||||
the following extended format specifiers for pointer types:
|
the following extended format specifiers for pointer types:
|
||||||
|
|
||||||
|
Pointer Types
|
||||||
|
=============
|
||||||
|
|
||||||
|
Pointers printed without a specifier extension (i.e unadorned %p) are
|
||||||
|
hashed to give a unique identifier without leaking kernel addresses to user
|
||||||
|
space. On 64 bit machines the first 32 bits are zeroed. If you _really_
|
||||||
|
want the address see %px below.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
%p abcdef12 or 00000000abcdef12
|
||||||
|
|
||||||
Symbols/Function Pointers
|
Symbols/Function Pointers
|
||||||
=========================
|
=========================
|
||||||
|
|
||||||
@ -85,18 +96,32 @@ Examples::
|
|||||||
printk("Faulted at %pS\n", (void *)regs->ip);
|
printk("Faulted at %pS\n", (void *)regs->ip);
|
||||||
printk(" %s%pB\n", (reliable ? "" : "? "), (void *)*stack);
|
printk(" %s%pB\n", (reliable ? "" : "? "), (void *)*stack);
|
||||||
|
|
||||||
|
|
||||||
Kernel Pointers
|
Kernel Pointers
|
||||||
===============
|
===============
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
%pK 0x01234567 or 0x0123456789abcdef
|
%pK 01234567 or 0123456789abcdef
|
||||||
|
|
||||||
For printing kernel pointers which should be hidden from unprivileged
|
For printing kernel pointers which should be hidden from unprivileged
|
||||||
users. The behaviour of ``%pK`` depends on the ``kptr_restrict sysctl`` - see
|
users. The behaviour of ``%pK`` depends on the ``kptr_restrict sysctl`` - see
|
||||||
Documentation/sysctl/kernel.txt for more details.
|
Documentation/sysctl/kernel.txt for more details.
|
||||||
|
|
||||||
|
Unmodified Addresses
|
||||||
|
====================
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
%px 01234567 or 0123456789abcdef
|
||||||
|
|
||||||
|
For printing pointers when you _really_ want to print the address. Please
|
||||||
|
consider whether or not you are leaking sensitive information about the
|
||||||
|
Kernel layout in memory before printing pointers with %px. %px is
|
||||||
|
functionally equivalent to %lx. %px is preferred to %lx because it is more
|
||||||
|
uniquely grep'able. If, in the future, we need to modify the way the Kernel
|
||||||
|
handles printing pointers it will be nice to be able to find the call
|
||||||
|
sites.
|
||||||
|
|
||||||
Struct Resources
|
Struct Resources
|
||||||
================
|
================
|
||||||
|
|
||||||
|
|||||||
@ -319,12 +319,12 @@ struct Scsi_Host:
|
|||||||
instance. If the reference count reaches 0 then the given instance
|
instance. If the reference count reaches 0 then the given instance
|
||||||
is freed
|
is freed
|
||||||
|
|
||||||
The Scsi_device structure has had reference counting infrastructure added.
|
The scsi_device structure has had reference counting infrastructure added.
|
||||||
This effectively spreads the ownership of struct Scsi_device instances
|
This effectively spreads the ownership of struct scsi_device instances
|
||||||
across the various SCSI layers which use them. Previously such instances
|
across the various SCSI layers which use them. Previously such instances
|
||||||
were exclusively owned by the mid level. See the access functions declared
|
were exclusively owned by the mid level. See the access functions declared
|
||||||
towards the end of include/scsi/scsi_device.h . If an LLD wants to keep
|
towards the end of include/scsi/scsi_device.h . If an LLD wants to keep
|
||||||
a copy of a pointer to a Scsi_device instance it should use scsi_device_get()
|
a copy of a pointer to a scsi_device instance it should use scsi_device_get()
|
||||||
to bump its reference count. When it is finished with the pointer it can
|
to bump its reference count. When it is finished with the pointer it can
|
||||||
use scsi_device_put() to decrement its reference count (and potentially
|
use scsi_device_put() to decrement its reference count (and potentially
|
||||||
delete it).
|
delete it).
|
||||||
|
|||||||
@ -158,10 +158,6 @@ Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any
|
|||||||
value lower than this limit will be ignored and the old configuration will be
|
value lower than this limit will be ignored and the old configuration will be
|
||||||
retained.
|
retained.
|
||||||
|
|
||||||
Note: the value of dirty_bytes also must be set greater than
|
|
||||||
dirty_background_bytes or the amount of memory corresponding to
|
|
||||||
dirty_background_ratio.
|
|
||||||
|
|
||||||
==============================================================
|
==============================================================
|
||||||
|
|
||||||
dirty_expire_centisecs
|
dirty_expire_centisecs
|
||||||
@ -181,9 +177,6 @@ generating disk writes will itself start writing out dirty data.
|
|||||||
|
|
||||||
The total available memory is not equal to total system memory.
|
The total available memory is not equal to total system memory.
|
||||||
|
|
||||||
Note: dirty_ratio must be set greater than dirty_background_ratio or
|
|
||||||
ratio corresponding to dirty_background_bytes.
|
|
||||||
|
|
||||||
==============================================================
|
==============================================================
|
||||||
|
|
||||||
dirty_writeback_centisecs
|
dirty_writeback_centisecs
|
||||||
|
|||||||
@ -2901,14 +2901,19 @@ userspace buffer and its length:
|
|||||||
|
|
||||||
struct kvm_s390_irq_state {
|
struct kvm_s390_irq_state {
|
||||||
__u64 buf;
|
__u64 buf;
|
||||||
__u32 flags;
|
__u32 flags; /* will stay unused for compatibility reasons */
|
||||||
__u32 len;
|
__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
|
Userspace passes in the above struct and for each pending interrupt a
|
||||||
struct kvm_s390_irq is copied to the provided buffer.
|
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
|
If -ENOBUFS is returned the buffer provided was too small and userspace
|
||||||
may retry with a bigger buffer.
|
may retry with a bigger buffer.
|
||||||
|
|
||||||
@ -2932,10 +2937,14 @@ containing a struct kvm_s390_irq_state:
|
|||||||
|
|
||||||
struct kvm_s390_irq_state {
|
struct kvm_s390_irq_state {
|
||||||
__u64 buf;
|
__u64 buf;
|
||||||
|
__u32 flags; /* will stay unused for compatibility reasons */
|
||||||
__u32 len;
|
__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
|
The userspace memory referenced by buf contains a struct kvm_s390_irq
|
||||||
for each interrupt to be injected into the guest.
|
for each interrupt to be injected into the guest.
|
||||||
If one of the interrupts could not be injected for some reason the
|
If one of the interrupts could not be injected for some reason the
|
||||||
|
|||||||
@ -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
|
original compressor. Once all pages are removed from an old zpool, the zpool
|
||||||
and its compressor are freed.
|
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
|
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.
|
||||||
|
|||||||
44
MAINTAINERS
44
MAINTAINERS
@ -554,13 +554,13 @@ S: Orphan
|
|||||||
F: Documentation/filesystems/affs.txt
|
F: Documentation/filesystems/affs.txt
|
||||||
F: fs/affs/
|
F: fs/affs/
|
||||||
|
|
||||||
AFS FILESYSTEM & AF_RXRPC SOCKET DOMAIN
|
AFS FILESYSTEM
|
||||||
M: David Howells <dhowells@redhat.com>
|
M: David Howells <dhowells@redhat.com>
|
||||||
L: linux-afs@lists.infradead.org
|
L: linux-afs@lists.infradead.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: fs/afs/
|
F: fs/afs/
|
||||||
F: include/net/af_rxrpc.h
|
F: include/trace/events/afs.h
|
||||||
F: net/rxrpc/af_rxrpc.c
|
F: Documentation/filesystems/afs.txt
|
||||||
W: https://www.infradead.org/~dhowells/kafs/
|
W: https://www.infradead.org/~dhowells/kafs/
|
||||||
|
|
||||||
AGPGART DRIVER
|
AGPGART DRIVER
|
||||||
@ -859,7 +859,8 @@ F: kernel/configs/android*
|
|||||||
ANDROID DRIVERS
|
ANDROID DRIVERS
|
||||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||||
M: Arve Hjønnevåg <arve@android.com>
|
M: Arve Hjønnevåg <arve@android.com>
|
||||||
M: Riley Andrews <riandrews@android.com>
|
M: Todd Kjos <tkjos@android.com>
|
||||||
|
M: Martijn Coenen <maco@android.com>
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
|
||||||
L: devel@driverdev.osuosl.org
|
L: devel@driverdev.osuosl.org
|
||||||
S: Supported
|
S: Supported
|
||||||
@ -2046,7 +2047,7 @@ F: arch/arm/boot/dts/uniphier*
|
|||||||
F: arch/arm/include/asm/hardware/cache-uniphier.h
|
F: arch/arm/include/asm/hardware/cache-uniphier.h
|
||||||
F: arch/arm/mach-uniphier/
|
F: arch/arm/mach-uniphier/
|
||||||
F: arch/arm/mm/cache-uniphier.c
|
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/bus/uniphier-system-bus.c
|
||||||
F: drivers/clk/uniphier/
|
F: drivers/clk/uniphier/
|
||||||
F: drivers/gpio/gpio-uniphier.c
|
F: drivers/gpio/gpio-uniphier.c
|
||||||
@ -5430,7 +5431,7 @@ F: drivers/media/tuners/fc2580*
|
|||||||
|
|
||||||
FCOE SUBSYSTEM (libfc, libfcoe, fcoe)
|
FCOE SUBSYSTEM (libfc, libfcoe, fcoe)
|
||||||
M: Johannes Thumshirn <jth@kernel.org>
|
M: Johannes Thumshirn <jth@kernel.org>
|
||||||
L: fcoe-devel@open-fcoe.org
|
L: linux-scsi@vger.kernel.org
|
||||||
W: www.Open-FCoE.org
|
W: www.Open-FCoE.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: drivers/scsi/libfc/
|
F: drivers/scsi/libfc/
|
||||||
@ -6174,7 +6175,6 @@ M: Jean Delvare <jdelvare@suse.com>
|
|||||||
M: Guenter Roeck <linux@roeck-us.net>
|
M: Guenter Roeck <linux@roeck-us.net>
|
||||||
L: linux-hwmon@vger.kernel.org
|
L: linux-hwmon@vger.kernel.org
|
||||||
W: http://hwmon.wiki.kernel.org/
|
W: http://hwmon.wiki.kernel.org/
|
||||||
T: quilt http://jdelvare.nerim.net/devel/linux/jdelvare-hwmon/
|
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/hwmon/
|
F: Documentation/hwmon/
|
||||||
@ -7767,6 +7767,7 @@ F: security/keys/
|
|||||||
|
|
||||||
KGDB / KDB /debug_core
|
KGDB / KDB /debug_core
|
||||||
M: Jason Wessel <jason.wessel@windriver.com>
|
M: Jason Wessel <jason.wessel@windriver.com>
|
||||||
|
M: Daniel Thompson <daniel.thompson@linaro.org>
|
||||||
W: http://kgdb.wiki.kernel.org/
|
W: http://kgdb.wiki.kernel.org/
|
||||||
L: kgdb-bugreport@lists.sourceforge.net
|
L: kgdb-bugreport@lists.sourceforge.net
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git
|
||||||
@ -9331,9 +9332,9 @@ F: drivers/gpu/drm/mxsfb/
|
|||||||
F: Documentation/devicetree/bindings/display/mxsfb-drm.txt
|
F: Documentation/devicetree/bindings/display/mxsfb-drm.txt
|
||||||
|
|
||||||
MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
|
MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
|
||||||
M: Hyong-Youb Kim <hykim@myri.com>
|
M: Chris Lee <christopher.lee@cspi.com>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
W: https://www.myricom.com/support/downloads/myri10ge.html
|
W: https://www.cspi.com/ethernet-products/support/downloads/
|
||||||
S: Supported
|
S: Supported
|
||||||
F: drivers/net/ethernet/myricom/myri10ge/
|
F: drivers/net/ethernet/myricom/myri10ge/
|
||||||
|
|
||||||
@ -11777,6 +11778,18 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git rtl8xxxu-deve
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/net/wireless/realtek/rtl8xxxu/
|
F: drivers/net/wireless/realtek/rtl8xxxu/
|
||||||
|
|
||||||
|
RXRPC SOCKETS (AF_RXRPC)
|
||||||
|
M: David Howells <dhowells@redhat.com>
|
||||||
|
L: linux-afs@lists.infradead.org
|
||||||
|
S: Supported
|
||||||
|
F: net/rxrpc/
|
||||||
|
F: include/keys/rxrpc-type.h
|
||||||
|
F: include/net/af_rxrpc.h
|
||||||
|
F: include/trace/events/rxrpc.h
|
||||||
|
F: include/uapi/linux/rxrpc.h
|
||||||
|
F: Documentation/networking/rxrpc.txt
|
||||||
|
W: https://www.infradead.org/~dhowells/kafs/
|
||||||
|
|
||||||
S3 SAVAGE FRAMEBUFFER DRIVER
|
S3 SAVAGE FRAMEBUFFER DRIVER
|
||||||
M: Antonino Daplas <adaplas@gmail.com>
|
M: Antonino Daplas <adaplas@gmail.com>
|
||||||
L: linux-fbdev@vger.kernel.org
|
L: linux-fbdev@vger.kernel.org
|
||||||
@ -12630,6 +12643,14 @@ S: Maintained
|
|||||||
F: drivers/ssb/
|
F: drivers/ssb/
|
||||||
F: include/linux/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
|
SONY MEMORYSTICK CARD SUPPORT
|
||||||
M: Alex Dubov <oakad@yahoo.com>
|
M: Alex Dubov <oakad@yahoo.com>
|
||||||
W: http://tifmxx.berlios.de/
|
W: http://tifmxx.berlios.de/
|
||||||
@ -13096,6 +13117,7 @@ F: drivers/dma/dw/
|
|||||||
|
|
||||||
SYNOPSYS DESIGNWARE ENTERPRISE ETHERNET DRIVER
|
SYNOPSYS DESIGNWARE ENTERPRISE ETHERNET DRIVER
|
||||||
M: Jie Deng <jiedeng@synopsys.com>
|
M: Jie Deng <jiedeng@synopsys.com>
|
||||||
|
M: Jose Abreu <Jose.Abreu@synopsys.com>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: drivers/net/ethernet/synopsys/
|
F: drivers/net/ethernet/synopsys/
|
||||||
@ -13648,10 +13670,8 @@ F: drivers/net/wireless/ti/
|
|||||||
F: include/linux/wl12xx.h
|
F: include/linux/wl12xx.h
|
||||||
|
|
||||||
TILE ARCHITECTURE
|
TILE ARCHITECTURE
|
||||||
M: Chris Metcalf <cmetcalf@mellanox.com>
|
|
||||||
W: http://www.mellanox.com/repository/solutions/tile-scm/
|
W: http://www.mellanox.com/repository/solutions/tile-scm/
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git
|
S: Orphan
|
||||||
S: Supported
|
|
||||||
F: arch/tile/
|
F: arch/tile/
|
||||||
F: drivers/char/tile-srom.c
|
F: drivers/char/tile-srom.c
|
||||||
F: drivers/edac/tile_edac.c
|
F: drivers/edac/tile_edac.c
|
||||||
|
|||||||
2
Makefile
2
Makefile
@ -2,7 +2,7 @@
|
|||||||
VERSION = 4
|
VERSION = 4
|
||||||
PATCHLEVEL = 15
|
PATCHLEVEL = 15
|
||||||
SUBLEVEL = 0
|
SUBLEVEL = 0
|
||||||
EXTRAVERSION = -rc1
|
EXTRAVERSION = -rc4
|
||||||
NAME = Fearless Coyote
|
NAME = Fearless Coyote
|
||||||
|
|
||||||
# *DOCUMENTATION*
|
# *DOCUMENTATION*
|
||||||
|
|||||||
@ -1,2 +1,4 @@
|
|||||||
# UAPI Header export list
|
# UAPI Header export list
|
||||||
include include/uapi/asm-generic/Kbuild.asm
|
include include/uapi/asm-generic/Kbuild.asm
|
||||||
|
|
||||||
|
generic-y += bpf_perf_event.h
|
||||||
|
|||||||
@ -3,6 +3,7 @@ include include/uapi/asm-generic/Kbuild.asm
|
|||||||
|
|
||||||
generic-y += auxvec.h
|
generic-y += auxvec.h
|
||||||
generic-y += bitsperlong.h
|
generic-y += bitsperlong.h
|
||||||
|
generic-y += bpf_perf_event.h
|
||||||
generic-y += errno.h
|
generic-y += errno.h
|
||||||
generic-y += fcntl.h
|
generic-y += fcntl.h
|
||||||
generic-y += ioctl.h
|
generic-y += ioctl.h
|
||||||
|
|||||||
@ -630,6 +630,7 @@
|
|||||||
reg-names = "phy";
|
reg-names = "phy";
|
||||||
status = "disabled";
|
status = "disabled";
|
||||||
ti,ctrl_mod = <&usb_ctrl_mod>;
|
ti,ctrl_mod = <&usb_ctrl_mod>;
|
||||||
|
#phy-cells = <0>;
|
||||||
};
|
};
|
||||||
|
|
||||||
usb0: usb@47401000 {
|
usb0: usb@47401000 {
|
||||||
@ -678,6 +679,7 @@
|
|||||||
reg-names = "phy";
|
reg-names = "phy";
|
||||||
status = "disabled";
|
status = "disabled";
|
||||||
ti,ctrl_mod = <&usb_ctrl_mod>;
|
ti,ctrl_mod = <&usb_ctrl_mod>;
|
||||||
|
#phy-cells = <0>;
|
||||||
};
|
};
|
||||||
|
|
||||||
usb1: usb@47401800 {
|
usb1: usb@47401800 {
|
||||||
|
|||||||
@ -927,7 +927,8 @@
|
|||||||
reg = <0x48038000 0x2000>,
|
reg = <0x48038000 0x2000>,
|
||||||
<0x46000000 0x400000>;
|
<0x46000000 0x400000>;
|
||||||
reg-names = "mpu", "dat";
|
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";
|
interrupt-names = "tx", "rx";
|
||||||
status = "disabled";
|
status = "disabled";
|
||||||
dmas = <&edma 8 2>,
|
dmas = <&edma 8 2>,
|
||||||
@ -941,7 +942,8 @@
|
|||||||
reg = <0x4803C000 0x2000>,
|
reg = <0x4803C000 0x2000>,
|
||||||
<0x46400000 0x400000>;
|
<0x46400000 0x400000>;
|
||||||
reg-names = "mpu", "dat";
|
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";
|
interrupt-names = "tx", "rx";
|
||||||
status = "disabled";
|
status = "disabled";
|
||||||
dmas = <&edma 10 2>,
|
dmas = <&edma 10 2>,
|
||||||
|
|||||||
@ -301,8 +301,8 @@
|
|||||||
status = "okay";
|
status = "okay";
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&spi0_pins>;
|
pinctrl-0 = <&spi0_pins>;
|
||||||
dmas = <&edma 16
|
dmas = <&edma 16 0
|
||||||
&edma 17>;
|
&edma 17 0>;
|
||||||
dma-names = "tx0", "rx0";
|
dma-names = "tx0", "rx0";
|
||||||
|
|
||||||
flash: w25q64cvzpig@0 {
|
flash: w25q64cvzpig@0 {
|
||||||
|
|||||||
@ -236,6 +236,7 @@
|
|||||||
usb3_phy: usb3_phy {
|
usb3_phy: usb3_phy {
|
||||||
compatible = "usb-nop-xceiv";
|
compatible = "usb-nop-xceiv";
|
||||||
vcc-supply = <®_xhci0_vbus>;
|
vcc-supply = <®_xhci0_vbus>;
|
||||||
|
#phy-cells = <0>;
|
||||||
};
|
};
|
||||||
|
|
||||||
reg_xhci0_vbus: xhci0-vbus {
|
reg_xhci0_vbus: xhci0-vbus {
|
||||||
|
|||||||
@ -66,6 +66,7 @@
|
|||||||
usb3_1_phy: usb3_1-phy {
|
usb3_1_phy: usb3_1-phy {
|
||||||
compatible = "usb-nop-xceiv";
|
compatible = "usb-nop-xceiv";
|
||||||
vcc-supply = <&usb3_1_vbus>;
|
vcc-supply = <&usb3_1_vbus>;
|
||||||
|
#phy-cells = <0>;
|
||||||
};
|
};
|
||||||
|
|
||||||
usb3_1_vbus: usb3_1-vbus {
|
usb3_1_vbus: usb3_1-vbus {
|
||||||
|
|||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user