mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2026-05-10 23:33:01 -04:00
Merge branch 'linus' into locking/kcsan, to pick up fixes
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
@@ -18,7 +18,7 @@ may look as follows::
|
||||
|
||||
$ ls -l /sys/bus/acpi/devices/INT3404:00/
|
||||
total 0
|
||||
...
|
||||
...
|
||||
-r--r--r-- 1 root root 4096 Dec 13 20:38 state0
|
||||
-r--r--r-- 1 root root 4096 Dec 13 20:38 state1
|
||||
-r--r--r-- 1 root root 4096 Dec 13 20:38 state10
|
||||
@@ -38,7 +38,7 @@ where each of the "state*" files represents one performance state of the fan
|
||||
and contains a colon-separated list of 5 integer numbers (fields) with the
|
||||
following interpretation::
|
||||
|
||||
control_percent:trip_point_index:speed_rpm:noise_level_mdb:power_mw
|
||||
control_percent:trip_point_index:speed_rpm:noise_level_mdb:power_mw
|
||||
|
||||
* ``control_percent``: The percent value to be used to set the fan speed to a
|
||||
specific level using the _FSL object (0-100).
|
||||
|
||||
@@ -62,6 +62,30 @@ Or more shorter, written as following::
|
||||
In both styles, same key words are automatically merged when parsing it
|
||||
at boot time. So you can append similar trees or key-values.
|
||||
|
||||
Same-key Values
|
||||
---------------
|
||||
|
||||
It is prohibited that two or more values or arrays share a same-key.
|
||||
For example,::
|
||||
|
||||
foo = bar, baz
|
||||
foo = qux # !ERROR! we can not re-define same key
|
||||
|
||||
If you want to append the value to existing key as an array member,
|
||||
you can use ``+=`` operator. For example::
|
||||
|
||||
foo = bar, baz
|
||||
foo += qux
|
||||
|
||||
In this case, the key ``foo`` has ``bar``, ``baz`` and ``qux``.
|
||||
|
||||
However, a sub-key and a value can not co-exist under a parent key.
|
||||
For example, following config is NOT allowed.::
|
||||
|
||||
foo = value1
|
||||
foo.bar = value2 # !ERROR! subkey "bar" and value "value1" can NOT co-exist
|
||||
|
||||
|
||||
Comments
|
||||
--------
|
||||
|
||||
@@ -102,9 +126,13 @@ Boot Kernel With a Boot Config
|
||||
==============================
|
||||
|
||||
Since the boot configuration file is loaded with initrd, it will be added
|
||||
to the end of the initrd (initramfs) image file. The Linux kernel decodes
|
||||
the last part of the initrd image in memory to get the boot configuration
|
||||
data.
|
||||
to the end of the initrd (initramfs) image file with size, checksum and
|
||||
12-byte magic word as below.
|
||||
|
||||
[initrd][bootconfig][size(u32)][checksum(u32)][#BOOTCONFIG\n]
|
||||
|
||||
The Linux kernel decodes the last part of the initrd image in memory to
|
||||
get the boot configuration data.
|
||||
Because of this "piggyback" method, there is no need to change or
|
||||
update the boot loader and the kernel image itself.
|
||||
|
||||
|
||||
@@ -136,6 +136,10 @@
|
||||
dynamic table installation which will install SSDT
|
||||
tables to /sys/firmware/acpi/tables/dynamic.
|
||||
|
||||
acpi_no_watchdog [HW,ACPI,WDT]
|
||||
Ignore the ACPI-based watchdog interface (WDAT) and let
|
||||
a native driver control the watchdog device instead.
|
||||
|
||||
acpi_rsdp= [ACPI,EFI,KEXEC]
|
||||
Pass the RSDP address to the kernel, mostly used
|
||||
on machines running EFI runtime service to boot the
|
||||
|
||||
@@ -110,6 +110,8 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Cavium | ThunderX GICv3 | #38539 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
|
||||
|
||||
@@ -551,6 +551,7 @@ options to your ``.config``:
|
||||
Once the kernel is built and installed, a simple
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
modprobe example-test
|
||||
|
||||
...will run the tests.
|
||||
|
||||
@@ -102,7 +102,7 @@ Required sub-node properties:
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Documentation/devicetree/bindings/power/power-domain.yaml
|
||||
[3] Documentation/devicetree/bindings/thermal/thermal.txt
|
||||
[4] Documentation/devicetree/bindings/sram/sram.txt
|
||||
[4] Documentation/devicetree/bindings/sram/sram.yaml
|
||||
[5] Documentation/devicetree/bindings/reset/reset.txt
|
||||
|
||||
Example:
|
||||
|
||||
@@ -109,7 +109,7 @@ Required properties:
|
||||
[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Documentation/devicetree/bindings/thermal/thermal.txt
|
||||
[3] Documentation/devicetree/bindings/sram/sram.txt
|
||||
[3] Documentation/devicetree/bindings/sram/sram.yaml
|
||||
[4] Documentation/devicetree/bindings/power/power-domain.yaml
|
||||
|
||||
Example:
|
||||
|
||||
@@ -62,7 +62,7 @@ Timer node:
|
||||
|
||||
Syscon reboot node:
|
||||
|
||||
See Documentation/devicetree/bindings/power/reset/syscon-reboot.txt for the
|
||||
See Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml for the
|
||||
detailed list of properties, the two values defined below are specific to the
|
||||
BCM6328-style timer:
|
||||
|
||||
|
||||
@@ -216,7 +216,7 @@ properties:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
||||
description: |
|
||||
List of phandles to idle state nodes supported
|
||||
by this cpu (see ./idle-states.txt).
|
||||
by this cpu (see ./idle-states.yaml).
|
||||
|
||||
capacity-dmips-mhz:
|
||||
$ref: '/schemas/types.yaml#/definitions/uint32'
|
||||
|
||||
@@ -160,7 +160,7 @@ properties:
|
||||
items:
|
||||
- enum:
|
||||
- armadeus,imx6dl-apf6 # APF6 (Solo) SoM
|
||||
- armadeus,imx6dl-apf6dldev # APF6 (Solo) SoM on APF6Dev board
|
||||
- armadeus,imx6dl-apf6dev # APF6 (Solo) SoM on APF6Dev board
|
||||
- eckelmann,imx6dl-ci4x10
|
||||
- emtrion,emcon-mx6 # emCON-MX6S or emCON-MX6DL SoM
|
||||
- emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
* Hisilicon Hi3519 System Controller Block
|
||||
|
||||
This bindings use the following binding:
|
||||
Documentation/devicetree/bindings/mfd/syscon.txt
|
||||
Documentation/devicetree/bindings/mfd/syscon.yaml
|
||||
|
||||
Required properties:
|
||||
- compatible: "hisilicon,hi3519-sysctrl".
|
||||
|
||||
@@ -81,4 +81,4 @@ Example:
|
||||
};
|
||||
};
|
||||
|
||||
[1]. Documentation/devicetree/bindings/arm/idle-states.txt
|
||||
[1]. Documentation/devicetree/bindings/arm/idle-states.yaml
|
||||
|
||||
@@ -17,7 +17,7 @@ am335x and am437x only:
|
||||
- pm-sram: Phandles to ocmcram nodes to be used for power management.
|
||||
First should be type 'protect-exec' for the driver to use to copy
|
||||
and run PM functions, second should be regular pool to be used for
|
||||
data region for code. See Documentation/devicetree/bindings/sram/sram.txt
|
||||
data region for code. See Documentation/devicetree/bindings/sram/sram.yaml
|
||||
for more details.
|
||||
|
||||
Examples:
|
||||
|
||||
@@ -100,13 +100,14 @@ properties:
|
||||
bindings in [1]) must specify this property.
|
||||
|
||||
[1] Kernel documentation - ARM idle states bindings
|
||||
Documentation/devicetree/bindings/arm/idle-states.txt
|
||||
|
||||
"#power-domain-cells":
|
||||
description:
|
||||
The number of cells in a PM domain specifier as per binding in [3].
|
||||
Must be 0 as to represent a single PM domain.
|
||||
Documentation/devicetree/bindings/arm/idle-states.yaml
|
||||
|
||||
patternProperties:
|
||||
"^power-domain-":
|
||||
allOf:
|
||||
- $ref: "../power/power-domain.yaml#"
|
||||
type: object
|
||||
description: |
|
||||
ARM systems can have multiple cores, sometimes in an hierarchical
|
||||
arrangement. This often, but not always, maps directly to the processor
|
||||
power topology of the system. Individual nodes in a topology have their
|
||||
@@ -122,14 +123,8 @@ properties:
|
||||
helps to implement support for OSI mode and OS implementations may choose
|
||||
to mandate it.
|
||||
|
||||
[3] Documentation/devicetree/bindings/power/power_domain.txt
|
||||
[4] Documentation/devicetree/bindings/power/domain-idle-state.txt
|
||||
|
||||
power-domains:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
||||
description:
|
||||
List of phandles and PM domain specifiers, as defined by bindings of the
|
||||
PM domain provider.
|
||||
[3] Documentation/devicetree/bindings/power/power-domain.yaml
|
||||
[4] Documentation/devicetree/bindings/power/domain-idle-state.yaml
|
||||
|
||||
required:
|
||||
- compatible
|
||||
@@ -199,7 +194,7 @@ examples:
|
||||
|
||||
CPU0: cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a53", "arm,armv8";
|
||||
compatible = "arm,cortex-a53";
|
||||
reg = <0x0>;
|
||||
enable-method = "psci";
|
||||
power-domains = <&CPU_PD0>;
|
||||
@@ -208,7 +203,7 @@ examples:
|
||||
|
||||
CPU1: cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57", "arm,armv8";
|
||||
compatible = "arm,cortex-a53";
|
||||
reg = <0x100>;
|
||||
enable-method = "psci";
|
||||
power-domains = <&CPU_PD1>;
|
||||
@@ -224,6 +219,9 @@ examples:
|
||||
exit-latency-us = <10>;
|
||||
min-residency-us = <100>;
|
||||
};
|
||||
};
|
||||
|
||||
domain-idle-states {
|
||||
|
||||
CLUSTER_RET: cluster-retention {
|
||||
compatible = "domain-idle-state";
|
||||
@@ -247,19 +245,19 @@ examples:
|
||||
compatible = "arm,psci-1.0";
|
||||
method = "smc";
|
||||
|
||||
CPU_PD0: cpu-pd0 {
|
||||
CPU_PD0: power-domain-cpu0 {
|
||||
#power-domain-cells = <0>;
|
||||
domain-idle-states = <&CPU_PWRDN>;
|
||||
power-domains = <&CLUSTER_PD>;
|
||||
};
|
||||
|
||||
CPU_PD1: cpu-pd1 {
|
||||
CPU_PD1: power-domain-cpu1 {
|
||||
#power-domain-cells = <0>;
|
||||
domain-idle-states = <&CPU_PWRDN>;
|
||||
power-domains = <&CLUSTER_PD>;
|
||||
};
|
||||
|
||||
CLUSTER_PD: cluster-pd {
|
||||
CLUSTER_PD: power-domain-cluster {
|
||||
#power-domain-cells = <0>;
|
||||
domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWRDN>;
|
||||
};
|
||||
|
||||
@@ -52,7 +52,7 @@ required:
|
||||
|
||||
examples:
|
||||
- |
|
||||
mlahb: ahb {
|
||||
mlahb: ahb@38000000 {
|
||||
compatible = "st,mlahb", "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
@@ -70,7 +70,6 @@ examples:
|
||||
#size-cells = <0>;
|
||||
|
||||
pmic@3e3 {
|
||||
compatible = "...";
|
||||
reg = <0x3e3>;
|
||||
|
||||
/* ... */
|
||||
|
||||
@@ -40,7 +40,7 @@ additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
osc24M: clk@01c20050 {
|
||||
osc24M: clk@1c20050 {
|
||||
#clock-cells = <0>;
|
||||
compatible = "allwinner,sun4i-a10-osc-clk";
|
||||
reg = <0x01c20050 0x4>;
|
||||
|
||||
@@ -41,7 +41,7 @@ additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clk@0600005c {
|
||||
clk@600005c {
|
||||
#clock-cells = <0>;
|
||||
compatible = "allwinner,sun9i-a80-gt-clk";
|
||||
reg = <0x0600005c 0x4>;
|
||||
|
||||
@@ -42,7 +42,7 @@ properties:
|
||||
be part of GCC and hence the TSENS properties can also be part
|
||||
of the GCC/clock-controller node.
|
||||
For more details on the TSENS properties please refer
|
||||
Documentation/devicetree/bindings/thermal/qcom-tsens.txt
|
||||
Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
|
||||
|
||||
nvmem-cell-names:
|
||||
minItems: 1
|
||||
|
||||
@@ -49,11 +49,7 @@ examples:
|
||||
resets = <&tcon_ch0_clk 0>;
|
||||
|
||||
port {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
tve0_in_tcon0: endpoint@0 {
|
||||
reg = <0>;
|
||||
tve0_in_tcon0: endpoint {
|
||||
remote-endpoint = <&tcon0_out_tve0>;
|
||||
};
|
||||
};
|
||||
|
||||
@@ -79,21 +79,15 @@ examples:
|
||||
#size-cells = <0>;
|
||||
|
||||
anx6345_in: port@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>;
|
||||
anx6345_in_tcon0: endpoint@0 {
|
||||
reg = <0>;
|
||||
anx6345_in_tcon0: endpoint {
|
||||
remote-endpoint = <&tcon0_out_anx6345>;
|
||||
};
|
||||
};
|
||||
|
||||
anx6345_out: port@1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <1>;
|
||||
anx6345_out_panel: endpoint@0 {
|
||||
reg = <0>;
|
||||
anx6345_out_panel: endpoint {
|
||||
remote-endpoint = <&panel_in_edp>;
|
||||
};
|
||||
};
|
||||
|
||||
@@ -37,6 +37,8 @@ examples:
|
||||
dsi@ff450000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0xff450000 0x1000>;
|
||||
|
||||
panel@0 {
|
||||
compatible = "leadtek,ltk500hd1829";
|
||||
reg = <0>;
|
||||
|
||||
@@ -37,6 +37,8 @@ examples:
|
||||
dsi@ff450000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0xff450000 0x1000>;
|
||||
|
||||
panel@0 {
|
||||
compatible = "xinpeng,xpp055c272";
|
||||
reg = <0>;
|
||||
|
||||
@@ -174,10 +174,6 @@ examples:
|
||||
};
|
||||
};
|
||||
|
||||
soc@1c00000 {
|
||||
lcdc0: lcdc@1c0c000 {
|
||||
compatible = "allwinner,sun4i-a10-lcdc";
|
||||
};
|
||||
};
|
||||
lcdc0: lcdc { };
|
||||
|
||||
...
|
||||
|
||||
@@ -37,7 +37,7 @@ Optional nodes:
|
||||
supports a single port with a single endpoint.
|
||||
|
||||
- See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
|
||||
Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting
|
||||
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt for connecting
|
||||
tfp410 DVI encoder or lcd panel to lcdc
|
||||
|
||||
[1] There is an errata about AM335x color wiring. For 16-bit color mode
|
||||
|
||||
@@ -143,7 +143,7 @@ examples:
|
||||
#size-cells = <2>;
|
||||
dma-coherent;
|
||||
dma-ranges;
|
||||
ranges;
|
||||
ranges = <0x0 0x30800000 0x0 0x30800000 0x0 0x05000000>;
|
||||
|
||||
ti,sci-dev-id = <118>;
|
||||
|
||||
@@ -169,16 +169,4 @@ examples:
|
||||
ti,sci-rm-range-rflow = <0x6>; /* GP RFLOW */
|
||||
};
|
||||
};
|
||||
|
||||
mcasp0: mcasp@02B00000 {
|
||||
dmas = <&main_udmap 0xc400>, <&main_udmap 0x4400>;
|
||||
dma-names = "tx", "rx";
|
||||
};
|
||||
|
||||
crypto: crypto@4E00000 {
|
||||
compatible = "ti,sa2ul-crypto";
|
||||
|
||||
dmas = <&main_udmap 0xc000>, <&main_udmap 0x4000>, <&main_udmap 0x4001>;
|
||||
dma-names = "tx", "rx1", "rx2";
|
||||
};
|
||||
};
|
||||
|
||||
@@ -84,31 +84,31 @@ examples:
|
||||
gpu_opp_table: opp_table0 {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp@533000000 {
|
||||
opp-533000000 {
|
||||
opp-hz = /bits/ 64 <533000000>;
|
||||
opp-microvolt = <1250000>;
|
||||
};
|
||||
opp@450000000 {
|
||||
opp-450000000 {
|
||||
opp-hz = /bits/ 64 <450000000>;
|
||||
opp-microvolt = <1150000>;
|
||||
};
|
||||
opp@400000000 {
|
||||
opp-400000000 {
|
||||
opp-hz = /bits/ 64 <400000000>;
|
||||
opp-microvolt = <1125000>;
|
||||
};
|
||||
opp@350000000 {
|
||||
opp-350000000 {
|
||||
opp-hz = /bits/ 64 <350000000>;
|
||||
opp-microvolt = <1075000>;
|
||||
};
|
||||
opp@266000000 {
|
||||
opp-266000000 {
|
||||
opp-hz = /bits/ 64 <266000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
};
|
||||
opp@160000000 {
|
||||
opp-160000000 {
|
||||
opp-hz = /bits/ 64 <160000000>;
|
||||
opp-microvolt = <925000>;
|
||||
};
|
||||
opp@100000000 {
|
||||
opp-100000000 {
|
||||
opp-hz = /bits/ 64 <100000000>;
|
||||
opp-microvolt = <912500>;
|
||||
};
|
||||
|
||||
@@ -138,31 +138,31 @@ examples:
|
||||
gpu_opp_table: opp_table0 {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp@533000000 {
|
||||
opp-533000000 {
|
||||
opp-hz = /bits/ 64 <533000000>;
|
||||
opp-microvolt = <1250000>;
|
||||
};
|
||||
opp@450000000 {
|
||||
opp-450000000 {
|
||||
opp-hz = /bits/ 64 <450000000>;
|
||||
opp-microvolt = <1150000>;
|
||||
};
|
||||
opp@400000000 {
|
||||
opp-400000000 {
|
||||
opp-hz = /bits/ 64 <400000000>;
|
||||
opp-microvolt = <1125000>;
|
||||
};
|
||||
opp@350000000 {
|
||||
opp-350000000 {
|
||||
opp-hz = /bits/ 64 <350000000>;
|
||||
opp-microvolt = <1075000>;
|
||||
};
|
||||
opp@266000000 {
|
||||
opp-266000000 {
|
||||
opp-hz = /bits/ 64 <266000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
};
|
||||
opp@160000000 {
|
||||
opp-160000000 {
|
||||
opp-hz = /bits/ 64 <160000000>;
|
||||
opp-microvolt = <925000>;
|
||||
};
|
||||
opp@100000000 {
|
||||
opp-100000000 {
|
||||
opp-hz = /bits/ 64 <100000000>;
|
||||
opp-microvolt = <912500>;
|
||||
};
|
||||
|
||||
@@ -123,7 +123,7 @@ examples:
|
||||
samsung,syscon-phandle = <&pmu_system_controller>;
|
||||
|
||||
/* NTC thermistor is a hwmon device */
|
||||
ncp15wb473@0 {
|
||||
ncp15wb473 {
|
||||
compatible = "murata,ncp15wb473";
|
||||
pullup-uv = <1800000>;
|
||||
pullup-ohm = <47000>;
|
||||
|
||||
@@ -62,7 +62,7 @@ required:
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c@00000000 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
gt928@5d {
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
Texas Instruments TWL family (twl4030) pwrbutton module
|
||||
|
||||
This module is part of the TWL4030. For more details about the whole
|
||||
chip see Documentation/devicetree/bindings/mfd/twl-familly.txt.
|
||||
chip see Documentation/devicetree/bindings/mfd/twl-family.txt.
|
||||
|
||||
This module provides a simple power button event via an Interrupt.
|
||||
|
||||
|
||||
@@ -85,7 +85,7 @@ properties:
|
||||
# LED will act as a back-light, controlled by the framebuffer system
|
||||
- backlight
|
||||
# LED will turn on (but for leds-gpio see "default-state" property in
|
||||
# Documentation/devicetree/bindings/leds/leds-gpio.txt)
|
||||
# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
|
||||
- default-on
|
||||
# LED "double" flashes at a load average based rate
|
||||
- heartbeat
|
||||
|
||||
@@ -5,7 +5,7 @@ where single bits in a certain register can turn on/off a
|
||||
single LED. The register bit LEDs appear as children to the
|
||||
syscon device, with the proper compatible string. For the
|
||||
syscon bindings see:
|
||||
Documentation/devicetree/bindings/mfd/syscon.txt
|
||||
Documentation/devicetree/bindings/mfd/syscon.yaml
|
||||
|
||||
Each LED is represented as a sub-node of the syscon device. Each
|
||||
node's name represents the name of the corresponding LED.
|
||||
|
||||
@@ -177,7 +177,7 @@ examples:
|
||||
};
|
||||
};
|
||||
|
||||
i2c5: i2c@4807c000 {
|
||||
i2c {
|
||||
clock-frequency = <400000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
@@ -32,7 +32,7 @@ Required only for "ti,emif-am3352" and "ti,emif-am4372":
|
||||
- sram : Phandles for generic sram driver nodes,
|
||||
first should be type 'protect-exec' for the driver to use to copy
|
||||
and run PM functions, second should be regular pool to be used for
|
||||
data region for code. See Documentation/devicetree/bindings/sram/sram.txt
|
||||
data region for code. See Documentation/devicetree/bindings/sram/sram.yaml
|
||||
for more details.
|
||||
|
||||
Optional properties:
|
||||
|
||||
@@ -97,14 +97,14 @@ examples:
|
||||
regulators {
|
||||
compatible = "maxim,max77650-regulator";
|
||||
|
||||
max77650_ldo: regulator@0 {
|
||||
max77650_ldo: regulator-ldo {
|
||||
regulator-compatible = "ldo";
|
||||
regulator-name = "max77650-ldo";
|
||||
regulator-min-microvolt = <1350000>;
|
||||
regulator-max-microvolt = <2937500>;
|
||||
};
|
||||
|
||||
max77650_sbb0: regulator@1 {
|
||||
max77650_sbb0: regulator-sbb0 {
|
||||
regulator-compatible = "sbb0";
|
||||
regulator-name = "max77650-sbb0";
|
||||
regulator-min-microvolt = <800000>;
|
||||
|
||||
@@ -26,8 +26,8 @@ Required properties:
|
||||
ldo6, ldo7, ldo8
|
||||
|
||||
- xxx-supply: Input voltage supply regulator.
|
||||
These entries are require if regulators are enabled for a device. Missing of these
|
||||
properties can cause the regulator registration fails.
|
||||
These entries are required if regulators are enabled for a device. Missing these
|
||||
properties can cause the regulator registration to fail.
|
||||
If some of input supply is powered through battery or always-on supply then
|
||||
also it is require to have these parameters with proper node handle of always
|
||||
on power supply.
|
||||
|
||||
@@ -20,7 +20,7 @@ RAVE SP consists of the following sub-devices:
|
||||
Device Description
|
||||
------ -----------
|
||||
rave-sp-wdt : Watchdog
|
||||
rave-sp-nvmem : Interface to onborad EEPROM
|
||||
rave-sp-nvmem : Interface to onboard EEPROM
|
||||
rave-sp-backlight : Display backlight
|
||||
rave-sp-hwmon : Interface to onboard hardware sensors
|
||||
rave-sp-leds : Interface to onboard LEDs
|
||||
|
||||
@@ -26,7 +26,7 @@ For generic IOMMU bindings, see
|
||||
Documentation/devicetree/bindings/iommu/iommu.txt.
|
||||
|
||||
For arm-smmu binding, see:
|
||||
Documentation/devicetree/bindings/iommu/arm,smmu.txt.
|
||||
Documentation/devicetree/bindings/iommu/arm,smmu.yaml.
|
||||
|
||||
Required properties:
|
||||
|
||||
|
||||
@@ -370,6 +370,7 @@ examples:
|
||||
mmc3: mmc@1c12000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0x1c12000 0x200>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc3_pins_a>;
|
||||
vmmc-supply = <®_vmmc3>;
|
||||
|
||||
@@ -27,7 +27,7 @@ Required properties of NAND chips:
|
||||
- reg: shall contain the native Chip Select ids from 0 to max supported by
|
||||
the cadence nand flash controller
|
||||
|
||||
See Documentation/devicetree/bindings/mtd/nand.txt for more details on
|
||||
See Documentation/devicetree/bindings/mtd/nand-controller.yaml for more details on
|
||||
generic bindings.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -45,7 +45,7 @@ Optional properties:
|
||||
switch queue
|
||||
|
||||
- resets: a single phandle and reset identifier pair. See
|
||||
Documentation/devicetree/binding/reset/reset.txt for details.
|
||||
Documentation/devicetree/bindings/reset/reset.txt for details.
|
||||
|
||||
- reset-names: If the "reset" property is specified, this property should have
|
||||
the value "switch" to denote the switch reset line.
|
||||
|
||||
@@ -110,6 +110,13 @@ PROPERTIES
|
||||
Usage: required
|
||||
Definition: See soc/fsl/qman.txt and soc/fsl/bman.txt
|
||||
|
||||
- fsl,erratum-a050385
|
||||
Usage: optional
|
||||
Value type: boolean
|
||||
Definition: A boolean property. Indicates the presence of the
|
||||
erratum A050385 which indicates that DMA transactions that are
|
||||
split can result in a FMan lock.
|
||||
|
||||
=============================================================================
|
||||
FMan MURAM Node
|
||||
|
||||
|
||||
@@ -76,6 +76,8 @@ examples:
|
||||
qfprom: eeprom@700000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x00700000 0x100000>;
|
||||
|
||||
wp-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
|
||||
|
||||
/* ... */
|
||||
|
||||
@@ -86,7 +86,7 @@ examples:
|
||||
#include <dt-bindings/clock/sun4i-a10-ccu.h>
|
||||
#include <dt-bindings/reset/sun4i-a10-ccu.h>
|
||||
|
||||
usbphy: phy@01c13400 {
|
||||
usbphy: phy@1c13400 {
|
||||
#phy-cells = <1>;
|
||||
compatible = "allwinner,sun4i-a10-usb-phy";
|
||||
reg = <0x01c13400 0x10>, <0x01c14800 0x4>, <0x01c1c800 0x4>;
|
||||
|
||||
@@ -17,7 +17,7 @@ description: |+
|
||||
"aspeed,ast2400-scu", "syscon", "simple-mfd"
|
||||
|
||||
Refer to the the bindings described in
|
||||
Documentation/devicetree/bindings/mfd/syscon.txt
|
||||
Documentation/devicetree/bindings/mfd/syscon.yaml
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -18,7 +18,7 @@ description: |+
|
||||
"aspeed,g5-scu", "syscon", "simple-mfd"
|
||||
|
||||
Refer to the the bindings described in
|
||||
Documentation/devicetree/bindings/mfd/syscon.txt
|
||||
Documentation/devicetree/bindings/mfd/syscon.yaml
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -17,7 +17,7 @@ description: |+
|
||||
"aspeed,ast2600-scu", "syscon", "simple-mfd"
|
||||
|
||||
Refer to the the bindings described in
|
||||
Documentation/devicetree/bindings/mfd/syscon.txt
|
||||
Documentation/devicetree/bindings/mfd/syscon.yaml
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -248,7 +248,7 @@ examples:
|
||||
};
|
||||
|
||||
//Example 3 pin groups
|
||||
pinctrl@60020000 {
|
||||
pinctrl {
|
||||
usart1_pins_a: usart1-0 {
|
||||
pins1 {
|
||||
pinmux = <STM32_PINMUX('A', 9, AF7)>;
|
||||
|
||||
@@ -18,7 +18,7 @@ description: |+
|
||||
"amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon"
|
||||
|
||||
Refer to the the bindings described in
|
||||
Documentation/devicetree/bindings/mfd/syscon.txt
|
||||
Documentation/devicetree/bindings/mfd/syscon.yaml
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -1,33 +0,0 @@
|
||||
PM Domain Idle State Node:
|
||||
|
||||
A domain idle state node represents the state parameters that will be used to
|
||||
select the state when there are no active components in the domain.
|
||||
|
||||
The state node has the following parameters -
|
||||
|
||||
- compatible:
|
||||
Usage: Required
|
||||
Value type: <string>
|
||||
Definition: Must be "domain-idle-state".
|
||||
|
||||
- entry-latency-us
|
||||
Usage: Required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: u32 value representing worst case latency in
|
||||
microseconds required to enter the idle state.
|
||||
The exit-latency-us duration may be guaranteed
|
||||
only after entry-latency-us has passed.
|
||||
|
||||
- exit-latency-us
|
||||
Usage: Required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: u32 value representing worst case latency
|
||||
in microseconds required to exit the idle state.
|
||||
|
||||
- min-residency-us
|
||||
Usage: Required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: u32 value representing minimum residency duration
|
||||
in microseconds after which the idle state will yield
|
||||
power benefits after overcoming the overhead in entering
|
||||
i the idle state.
|
||||
@@ -0,0 +1,64 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/power/domain-idle-state.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: PM Domain Idle States binding description
|
||||
|
||||
maintainers:
|
||||
- Ulf Hansson <ulf.hansson@linaro.org>
|
||||
|
||||
description:
|
||||
A domain idle state node represents the state parameters that will be used to
|
||||
select the state when there are no active components in the PM domain.
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: domain-idle-states
|
||||
|
||||
patternProperties:
|
||||
"^(cpu|cluster|domain)-":
|
||||
type: object
|
||||
description:
|
||||
Each state node represents a domain idle state description.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: domain-idle-state
|
||||
|
||||
entry-latency-us:
|
||||
description:
|
||||
The worst case latency in microseconds required to enter the idle
|
||||
state. Note that, the exit-latency-us duration may be guaranteed only
|
||||
after the entry-latency-us has passed.
|
||||
|
||||
exit-latency-us:
|
||||
description:
|
||||
The worst case latency in microseconds required to exit the idle
|
||||
state.
|
||||
|
||||
min-residency-us:
|
||||
description:
|
||||
The minimum residency duration in microseconds after which the idle
|
||||
state will yield power benefits, after overcoming the overhead while
|
||||
entering the idle state.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- entry-latency-us
|
||||
- exit-latency-us
|
||||
- min-residency-us
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
||||
domain-idle-states {
|
||||
domain_retention: domain-retention {
|
||||
compatible = "domain-idle-state";
|
||||
entry-latency-us = <20>;
|
||||
exit-latency-us = <40>;
|
||||
min-residency-us = <80>;
|
||||
};
|
||||
};
|
||||
...
|
||||
@@ -25,22 +25,20 @@ description: |+
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
pattern: "^(power-controller|power-domain)(@.*)?$"
|
||||
pattern: "^(power-controller|power-domain)([@-].*)?$"
|
||||
|
||||
domain-idle-states:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
A phandle of an idle-state that shall be soaked into a generic domain
|
||||
power state. The idle state definitions are compatible with
|
||||
domain-idle-state specified in
|
||||
Documentation/devicetree/bindings/power/domain-idle-state.txt
|
||||
phandles that are not compatible with domain-idle-state will be ignored.
|
||||
The domain-idle-state property reflects the idle state of this PM domain
|
||||
and not the idle states of the devices or sub-domains in the PM domain.
|
||||
Devices and sub-domains have their own idle-states independent
|
||||
of the parent domain's idle states. In the absence of this property,
|
||||
the domain would be considered as capable of being powered-on
|
||||
or powered-off.
|
||||
description: |
|
||||
Phandles of idle states that defines the available states for the
|
||||
power-domain provider. The idle state definitions are compatible with the
|
||||
domain-idle-state bindings, specified in ./domain-idle-state.yaml.
|
||||
|
||||
Note that, the domain-idle-state property reflects the idle states of this
|
||||
PM domain and not the idle states of the devices or sub-domains in the PM
|
||||
domain. Devices and sub-domains have their own idle states independent of
|
||||
the parent domain's idle states. In the absence of this property, the
|
||||
domain would be considered as capable of being powered-on or powered-off.
|
||||
|
||||
operating-points-v2:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
|
||||
@@ -109,4 +109,4 @@ Example:
|
||||
required-opps = <&domain1_opp_1>;
|
||||
};
|
||||
|
||||
[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
|
||||
[1]. Documentation/devicetree/bindings/power/domain-idle-state.yaml
|
||||
|
||||
@@ -161,7 +161,7 @@ The regulator node houses sub-nodes for each regulator within the device. Each
|
||||
sub-node is identified using the node's name, with valid values listed for each
|
||||
of the PMICs below.
|
||||
|
||||
pm8005:
|
||||
pm8004:
|
||||
s2, s5
|
||||
|
||||
pm8005:
|
||||
|
||||
@@ -191,7 +191,7 @@ patternProperties:
|
||||
|
||||
examples:
|
||||
- |
|
||||
xyzreg: regulator@0 {
|
||||
xyzreg: regulator {
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <2500000>;
|
||||
regulator-always-on;
|
||||
|
||||
@@ -23,7 +23,11 @@ properties:
|
||||
description: Global reset register offset and bit offset.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
- maxItems: 2
|
||||
items:
|
||||
- description: Register offset
|
||||
- description: Register bit offset
|
||||
minimum: 0
|
||||
maximum: 31
|
||||
|
||||
"#reset-cells":
|
||||
minimum: 2
|
||||
|
||||
@@ -3,4 +3,4 @@ STMicroelectronics STM32MP1 Peripheral Reset Controller
|
||||
|
||||
The RCC IP is both a reset and a clock controller.
|
||||
|
||||
Please see Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.txt
|
||||
Please see Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
|
||||
|
||||
@@ -36,7 +36,7 @@ SAI subnodes required properties:
|
||||
- clock-names: Must contain "sai_ck".
|
||||
Must also contain "MCLK", if SAI shares a master clock,
|
||||
with a SAI set as MCLK clock provider.
|
||||
- dmas: see Documentation/devicetree/bindings/dma/stm32-dma.txt
|
||||
- dmas: see Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
|
||||
- dma-names: identifier string for each DMA request line
|
||||
"tx": if sai sub-block is configured as playback DAI
|
||||
"rx": if sai sub-block is configured as capture DAI
|
||||
|
||||
@@ -10,7 +10,7 @@ Required properties:
|
||||
- clock-names: must contain "kclk"
|
||||
- interrupts: cpu DAI interrupt line
|
||||
- dmas: DMA specifiers for audio data DMA and iec control flow DMA
|
||||
See STM32 DMA bindings, Documentation/devicetree/bindings/dma/stm32-dma.txt
|
||||
See STM32 DMA bindings, Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
|
||||
- dma-names: two dmas have to be defined, "rx" and "rx-ctrl"
|
||||
|
||||
Optional properties:
|
||||
|
||||
@@ -49,7 +49,7 @@ properties:
|
||||
dmas:
|
||||
description: |
|
||||
DMA specifiers for tx and rx dma. DMA fifo mode must be used. See
|
||||
the STM32 DMA bindings Documentation/devicetree/bindings/dma/stm32-dma.txt.
|
||||
the STM32 DMA bindings Documentation/devicetree/bindings/dma/st,stm32-dma.yaml.
|
||||
items:
|
||||
- description: rx DMA channel
|
||||
- description: tx DMA channel
|
||||
|
||||
@@ -125,7 +125,7 @@ examples:
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
|
||||
sram_a: sram@00000000 {
|
||||
sram_a: sram@0 {
|
||||
compatible = "mmio-sram";
|
||||
reg = <0x00000000 0xc000>;
|
||||
#address-cells = <1>;
|
||||
|
||||
@@ -17,7 +17,7 @@ description: |+
|
||||
"brcm,bcm2711-avs-monitor", "syscon", "simple-mfd"
|
||||
|
||||
Refer to the the bindings described in
|
||||
Documentation/devicetree/bindings/mfd/syscon.txt
|
||||
Documentation/devicetree/bindings/mfd/syscon.yaml
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -87,7 +87,7 @@ additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
timer {
|
||||
timer@1c20c00 {
|
||||
compatible = "allwinner,sun4i-a10-timer";
|
||||
reg = <0x01c20c00 0x400>;
|
||||
interrupts = <22>,
|
||||
|
||||
@@ -151,8 +151,8 @@ The details of these operations are:
|
||||
Note that callbacks will always be invoked from the DMA
|
||||
engines tasklet, never from interrupt context.
|
||||
|
||||
Optional: per descriptor metadata
|
||||
---------------------------------
|
||||
**Optional: per descriptor metadata**
|
||||
|
||||
DMAengine provides two ways for metadata support.
|
||||
|
||||
DESC_METADATA_CLIENT
|
||||
@@ -199,12 +199,15 @@ Optional: per descriptor metadata
|
||||
DESC_METADATA_CLIENT
|
||||
|
||||
- DMA_MEM_TO_DEV / DEV_MEM_TO_MEM:
|
||||
|
||||
1. prepare the descriptor (dmaengine_prep_*)
|
||||
construct the metadata in the client's buffer
|
||||
2. use dmaengine_desc_attach_metadata() to attach the buffer to the
|
||||
descriptor
|
||||
3. submit the transfer
|
||||
|
||||
- DMA_DEV_TO_MEM:
|
||||
|
||||
1. prepare the descriptor (dmaengine_prep_*)
|
||||
2. use dmaengine_desc_attach_metadata() to attach the buffer to the
|
||||
descriptor
|
||||
@@ -215,6 +218,7 @@ Optional: per descriptor metadata
|
||||
DESC_METADATA_ENGINE
|
||||
|
||||
- DMA_MEM_TO_DEV / DEV_MEM_TO_MEM:
|
||||
|
||||
1. prepare the descriptor (dmaengine_prep_*)
|
||||
2. use dmaengine_desc_get_metadata_ptr() to get the pointer to the
|
||||
engine's metadata area
|
||||
@@ -222,7 +226,9 @@ Optional: per descriptor metadata
|
||||
4. use dmaengine_desc_set_metadata_len() to tell the DMA engine the
|
||||
amount of data the client has placed into the metadata buffer
|
||||
5. submit the transfer
|
||||
|
||||
- DMA_DEV_TO_MEM:
|
||||
|
||||
1. prepare the descriptor (dmaengine_prep_*)
|
||||
2. submit the transfer
|
||||
3. on transfer completion, use dmaengine_desc_get_metadata_ptr() to get
|
||||
@@ -278,8 +284,8 @@ Optional: per descriptor metadata
|
||||
|
||||
void dma_async_issue_pending(struct dma_chan *chan);
|
||||
|
||||
Further APIs:
|
||||
-------------
|
||||
Further APIs
|
||||
------------
|
||||
|
||||
1. Terminate APIs
|
||||
|
||||
|
||||
@@ -164,9 +164,9 @@ file.
|
||||
void __iomem *base;
|
||||
};
|
||||
|
||||
struct dentry *debugfs_create_regset32(const char *name, umode_t mode,
|
||||
struct dentry *parent,
|
||||
struct debugfs_regset32 *regset);
|
||||
debugfs_create_regset32(const char *name, umode_t mode,
|
||||
struct dentry *parent,
|
||||
struct debugfs_regset32 *regset);
|
||||
|
||||
void debugfs_print_regs32(struct seq_file *s, struct debugfs_reg32 *regs,
|
||||
int nregs, void __iomem *base, char *prefix);
|
||||
|
||||
@@ -850,3 +850,11 @@ business doing so.
|
||||
d_alloc_pseudo() is internal-only; uses outside of alloc_file_pseudo() are
|
||||
very suspect (and won't work in modules). Such uses are very likely to
|
||||
be misspelled d_alloc_anon().
|
||||
|
||||
---
|
||||
|
||||
**mandatory**
|
||||
|
||||
[should've been added in 2016] stale comment in finish_open() nonwithstanding,
|
||||
failure exits in ->atomic_open() instances should *NOT* fput() the file,
|
||||
no matter what. Everything is handled by the caller.
|
||||
|
||||
@@ -20,8 +20,7 @@ Usage Notes
|
||||
-----------
|
||||
|
||||
This driver does not auto-detect devices. You will have to instantiate the
|
||||
devices explicitly. Please see Documentation/i2c/instantiating-devices for
|
||||
details.
|
||||
devices explicitly. Please see :doc:`/i2c/instantiating-devices` for details.
|
||||
|
||||
|
||||
Sysfs entries
|
||||
|
||||
@@ -237,7 +237,7 @@ This is solely useful to speed up test compiles.
|
||||
KBUILD_EXTRA_SYMBOLS
|
||||
--------------------
|
||||
For modules that use symbols from other modules.
|
||||
See more details in modules.txt.
|
||||
See more details in modules.rst.
|
||||
|
||||
ALLSOURCE_ARCHS
|
||||
---------------
|
||||
|
||||
@@ -44,7 +44,7 @@ intermediate::
|
||||
def_bool y
|
||||
|
||||
Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
|
||||
dependency as explained in kconfig-language.txt.
|
||||
dependency as explained in kconfig-language.rst.
|
||||
|
||||
|
||||
Variables
|
||||
|
||||
@@ -765,7 +765,7 @@ is not sufficient this sometimes needs to be explicit.
|
||||
Example::
|
||||
|
||||
#arch/x86/boot/Makefile
|
||||
subdir- := compressed/
|
||||
subdir- := compressed
|
||||
|
||||
The above assignment instructs kbuild to descend down in the
|
||||
directory compressed/ when "make clean" is executed.
|
||||
@@ -924,7 +924,7 @@ When kbuild executes, the following steps are followed (roughly):
|
||||
$(KBUILD_AFLAGS_MODULE) is used to add arch-specific options that
|
||||
are used for assembler.
|
||||
|
||||
From commandline AFLAGS_MODULE shall be used (see kbuild.txt).
|
||||
From commandline AFLAGS_MODULE shall be used (see kbuild.rst).
|
||||
|
||||
KBUILD_CFLAGS_KERNEL
|
||||
$(CC) options specific for built-in
|
||||
@@ -937,7 +937,7 @@ When kbuild executes, the following steps are followed (roughly):
|
||||
|
||||
$(KBUILD_CFLAGS_MODULE) is used to add arch-specific options that
|
||||
are used for $(CC).
|
||||
From commandline CFLAGS_MODULE shall be used (see kbuild.txt).
|
||||
From commandline CFLAGS_MODULE shall be used (see kbuild.rst).
|
||||
|
||||
KBUILD_LDFLAGS_MODULE
|
||||
Options for $(LD) when linking modules
|
||||
@@ -945,7 +945,7 @@ When kbuild executes, the following steps are followed (roughly):
|
||||
$(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
|
||||
used when linking modules. This is often a linker script.
|
||||
|
||||
From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
|
||||
From commandline LDFLAGS_MODULE shall be used (see kbuild.rst).
|
||||
|
||||
KBUILD_LDS
|
||||
|
||||
@@ -1379,9 +1379,6 @@ See subsequent chapter for the syntax of the Kbuild file.
|
||||
in arch/$(ARCH)/include/(uapi/)/asm, Kbuild will automatically generate
|
||||
a wrapper of the asm-generic one.
|
||||
|
||||
The convention is to list one subdir per line and
|
||||
preferably in alphabetic order.
|
||||
|
||||
8 Kbuild Variables
|
||||
==================
|
||||
|
||||
|
||||
@@ -470,9 +470,9 @@ build.
|
||||
|
||||
The syntax of the Module.symvers file is::
|
||||
|
||||
<CRC> <Symbol> <Namespace> <Module> <Export Type>
|
||||
<CRC> <Symbol> <Module> <Export Type> <Namespace>
|
||||
|
||||
0xe1cc2a05 usb_stor_suspend USB_STORAGE drivers/usb/storage/usb-storage EXPORT_SYMBOL_GPL
|
||||
0xe1cc2a05 usb_stor_suspend drivers/usb/storage/usb-storage EXPORT_SYMBOL_GPL USB_STORAGE
|
||||
|
||||
The fields are separated by tabs and values may be empty (e.g.
|
||||
if no namespace is defined for an exported symbol).
|
||||
|
||||
@@ -40,9 +40,6 @@ example usage
|
||||
# Delete a snapshot using:
|
||||
$ devlink region del pci/0000:00:05.0/cr-space snapshot 1
|
||||
|
||||
# Trigger (request) a snapshot be taken:
|
||||
$ devlink region trigger pci/0000:00:05.0/cr-space
|
||||
|
||||
# Dump a snapshot:
|
||||
$ devlink region dump pci/0000:00:05.0/fw-health snapshot 1
|
||||
0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30
|
||||
|
||||
@@ -8,9 +8,9 @@ Overview
|
||||
========
|
||||
|
||||
The net_failover driver provides an automated failover mechanism via APIs
|
||||
to create and destroy a failover master netdev and mananges a primary and
|
||||
to create and destroy a failover master netdev and manages a primary and
|
||||
standby slave netdevs that get registered via the generic failover
|
||||
infrastructrure.
|
||||
infrastructure.
|
||||
|
||||
The failover netdev acts a master device and controls 2 slave devices. The
|
||||
original paravirtual interface is registered as 'standby' slave netdev and
|
||||
@@ -29,7 +29,7 @@ virtio-net accelerated datapath: STANDBY mode
|
||||
=============================================
|
||||
|
||||
net_failover enables hypervisor controlled accelerated datapath to virtio-net
|
||||
enabled VMs in a transparent manner with no/minimal guest userspace chanages.
|
||||
enabled VMs in a transparent manner with no/minimal guest userspace changes.
|
||||
|
||||
To support this, the hypervisor needs to enable VIRTIO_NET_F_STANDBY
|
||||
feature on the virtio-net interface and assign the same MAC address to both
|
||||
|
||||
@@ -487,8 +487,9 @@ phy_register_fixup_for_id()::
|
||||
The stubs set one of the two matching criteria, and set the other one to
|
||||
match anything.
|
||||
|
||||
When phy_register_fixup() or \*_for_uid()/\*_for_id() is called at module,
|
||||
unregister fixup and free allocate memory are required.
|
||||
When phy_register_fixup() or \*_for_uid()/\*_for_id() is called at module load
|
||||
time, the module needs to unregister the fixup and free allocated memory when
|
||||
it's unloaded.
|
||||
|
||||
Call one of following function before unloading module::
|
||||
|
||||
|
||||
@@ -159,7 +159,7 @@ Socket Interface
|
||||
set SO_RDS_TRANSPORT on a socket for which the transport has
|
||||
been previously attached explicitly (by SO_RDS_TRANSPORT) or
|
||||
implicitly (via bind(2)) will return an error of EOPNOTSUPP.
|
||||
An attempt to set SO_RDS_TRANSPPORT to RDS_TRANS_NONE will
|
||||
An attempt to set SO_RDS_TRANSPORT to RDS_TRANS_NONE will
|
||||
always return EINVAL.
|
||||
|
||||
RDMA for RDS
|
||||
|
||||
@@ -13,7 +13,6 @@ Power Management
|
||||
drivers-testing
|
||||
energy-model
|
||||
freezing-of-tasks
|
||||
interface
|
||||
opp
|
||||
pci
|
||||
pm_qos_interface
|
||||
|
||||
@@ -30,4 +30,4 @@ if [ -n "$parallel" ] ; then
|
||||
parallel="-j$parallel"
|
||||
fi
|
||||
|
||||
exec "$sphinx" "$parallel" "$@"
|
||||
exec "$sphinx" $parallel "$@"
|
||||
|
||||
@@ -4611,35 +4611,38 @@ unpins the VPA pages and releases all the device pages that are used to
|
||||
track the secure pages by hypervisor.
|
||||
|
||||
4.122 KVM_S390_NORMAL_RESET
|
||||
---------------------------
|
||||
|
||||
Capability: KVM_CAP_S390_VCPU_RESETS
|
||||
Architectures: s390
|
||||
Type: vcpu ioctl
|
||||
Parameters: none
|
||||
Returns: 0
|
||||
:Capability: KVM_CAP_S390_VCPU_RESETS
|
||||
:Architectures: s390
|
||||
:Type: vcpu ioctl
|
||||
:Parameters: none
|
||||
:Returns: 0
|
||||
|
||||
This ioctl resets VCPU registers and control structures according to
|
||||
the cpu reset definition in the POP (Principles Of Operation).
|
||||
|
||||
4.123 KVM_S390_INITIAL_RESET
|
||||
----------------------------
|
||||
|
||||
Capability: none
|
||||
Architectures: s390
|
||||
Type: vcpu ioctl
|
||||
Parameters: none
|
||||
Returns: 0
|
||||
:Capability: none
|
||||
:Architectures: s390
|
||||
:Type: vcpu ioctl
|
||||
:Parameters: none
|
||||
:Returns: 0
|
||||
|
||||
This ioctl resets VCPU registers and control structures according to
|
||||
the initial cpu reset definition in the POP. However, the cpu is not
|
||||
put into ESA mode. This reset is a superset of the normal reset.
|
||||
|
||||
4.124 KVM_S390_CLEAR_RESET
|
||||
--------------------------
|
||||
|
||||
Capability: KVM_CAP_S390_VCPU_RESETS
|
||||
Architectures: s390
|
||||
Type: vcpu ioctl
|
||||
Parameters: none
|
||||
Returns: 0
|
||||
:Capability: KVM_CAP_S390_VCPU_RESETS
|
||||
:Architectures: s390
|
||||
:Type: vcpu ioctl
|
||||
:Parameters: none
|
||||
:Returns: 0
|
||||
|
||||
This ioctl resets VCPU registers and control structures according to
|
||||
the clear cpu reset definition in the POP. However, the cpu is not put
|
||||
|
||||
@@ -19,7 +19,6 @@ x86-specific Documentation
|
||||
tlb
|
||||
mtrr
|
||||
pat
|
||||
intel_mpx
|
||||
intel-iommu
|
||||
intel_txt
|
||||
amd-memory-encryption
|
||||
|
||||
Reference in New Issue
Block a user