Linux 5.6-rc7
-----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAl54EZgeHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGLpwIAJv475oyWJDefyZn Va5GF+LgR3CMGnfOQXyLXphFUU0fYQtuHb6E5w2hmMpovNrlbpzuypuOetqN1gtQ DpDgt6htHlBAJCNkNnHOjEARmMZo64D2dnLlTfa6fjJMc4tg3yk/oMFXFpiP0kdd ena4DetB293IF2EjP7RWfVbXzbZzG4sLmIsOmUiFH1H1nhTV8tZWG06KvUcwuCSU AfrXiOaVj6npiShszjdODYaFRL6mYh5es7q02wQpKeWdZHRU8IuKTgywiOjh6uD4 J2bXvz0qbDN/2Zgj73H8EfkAP7zm6nCHifQiUm9uRsjzpcfjFRYIn+4/4LAzCIjm VI8uvdA= =/NN5 -----END PGP SIGNATURE----- Merge tag 'v5.6-rc7' into devel Linux 5.6-rc7
This commit is contained in:
Коммит
06dd3f31cb
|
@ -86,6 +86,8 @@ ForEachMacros:
|
|||
- 'bio_for_each_segment_all'
|
||||
- 'bio_list_for_each'
|
||||
- 'bip_for_each_vec'
|
||||
- 'bitmap_for_each_clear_region'
|
||||
- 'bitmap_for_each_set_region'
|
||||
- 'blkg_for_each_descendant_post'
|
||||
- 'blkg_for_each_descendant_pre'
|
||||
- 'blk_queue_for_each_rl'
|
||||
|
@ -115,6 +117,7 @@ ForEachMacros:
|
|||
- 'drm_client_for_each_connector_iter'
|
||||
- 'drm_client_for_each_modeset'
|
||||
- 'drm_connector_for_each_possible_encoder'
|
||||
- 'drm_for_each_bridge_in_chain'
|
||||
- 'drm_for_each_connector_iter'
|
||||
- 'drm_for_each_crtc'
|
||||
- 'drm_for_each_encoder'
|
||||
|
@ -136,9 +139,10 @@ ForEachMacros:
|
|||
- 'for_each_bio'
|
||||
- 'for_each_board_func_rsrc'
|
||||
- 'for_each_bvec'
|
||||
- 'for_each_card_auxs'
|
||||
- 'for_each_card_auxs_safe'
|
||||
- 'for_each_card_components'
|
||||
- 'for_each_card_links'
|
||||
- 'for_each_card_links_safe'
|
||||
- 'for_each_card_pre_auxs'
|
||||
- 'for_each_card_prelinks'
|
||||
- 'for_each_card_rtds'
|
||||
- 'for_each_card_rtds_safe'
|
||||
|
@ -166,6 +170,7 @@ ForEachMacros:
|
|||
- 'for_each_dpcm_fe'
|
||||
- 'for_each_drhd_unit'
|
||||
- 'for_each_dss_dev'
|
||||
- 'for_each_efi_handle'
|
||||
- 'for_each_efi_memory_desc'
|
||||
- 'for_each_efi_memory_desc_in_map'
|
||||
- 'for_each_element'
|
||||
|
@ -190,6 +195,7 @@ ForEachMacros:
|
|||
- 'for_each_lru'
|
||||
- 'for_each_matching_node'
|
||||
- 'for_each_matching_node_and_match'
|
||||
- 'for_each_member'
|
||||
- 'for_each_memblock'
|
||||
- 'for_each_memblock_type'
|
||||
- 'for_each_memcg_cache_index'
|
||||
|
@ -200,9 +206,11 @@ ForEachMacros:
|
|||
- 'for_each_msi_entry'
|
||||
- 'for_each_msi_entry_safe'
|
||||
- 'for_each_net'
|
||||
- 'for_each_net_continue_reverse'
|
||||
- 'for_each_netdev'
|
||||
- 'for_each_netdev_continue'
|
||||
- 'for_each_netdev_continue_rcu'
|
||||
- 'for_each_netdev_continue_reverse'
|
||||
- 'for_each_netdev_feature'
|
||||
- 'for_each_netdev_in_bond_rcu'
|
||||
- 'for_each_netdev_rcu'
|
||||
|
@ -254,10 +262,10 @@ ForEachMacros:
|
|||
- 'for_each_reserved_mem_region'
|
||||
- 'for_each_rtd_codec_dai'
|
||||
- 'for_each_rtd_codec_dai_rollback'
|
||||
- 'for_each_rtdcom'
|
||||
- 'for_each_rtdcom_safe'
|
||||
- 'for_each_rtd_components'
|
||||
- 'for_each_set_bit'
|
||||
- 'for_each_set_bit_from'
|
||||
- 'for_each_set_clump8'
|
||||
- 'for_each_sg'
|
||||
- 'for_each_sg_dma_page'
|
||||
- 'for_each_sg_page'
|
||||
|
@ -267,6 +275,7 @@ ForEachMacros:
|
|||
- 'for_each_subelement_id'
|
||||
- '__for_each_thread'
|
||||
- 'for_each_thread'
|
||||
- 'for_each_wakeup_source'
|
||||
- 'for_each_zone'
|
||||
- 'for_each_zone_zonelist'
|
||||
- 'for_each_zone_zonelist_nodemask'
|
||||
|
@ -330,6 +339,7 @@ ForEachMacros:
|
|||
- 'list_for_each'
|
||||
- 'list_for_each_codec'
|
||||
- 'list_for_each_codec_safe'
|
||||
- 'list_for_each_continue'
|
||||
- 'list_for_each_entry'
|
||||
- 'list_for_each_entry_continue'
|
||||
- 'list_for_each_entry_continue_rcu'
|
||||
|
@ -351,6 +361,7 @@ ForEachMacros:
|
|||
- 'llist_for_each_entry'
|
||||
- 'llist_for_each_entry_safe'
|
||||
- 'llist_for_each_safe'
|
||||
- 'mci_for_each_dimm'
|
||||
- 'media_device_for_each_entity'
|
||||
- 'media_device_for_each_intf'
|
||||
- 'media_device_for_each_link'
|
||||
|
@ -444,10 +455,16 @@ ForEachMacros:
|
|||
- 'virtio_device_for_each_vq'
|
||||
- 'xa_for_each'
|
||||
- 'xa_for_each_marked'
|
||||
- 'xa_for_each_range'
|
||||
- 'xa_for_each_start'
|
||||
- 'xas_for_each'
|
||||
- 'xas_for_each_conflict'
|
||||
- 'xas_for_each_marked'
|
||||
- 'xbc_array_for_each_value'
|
||||
- 'xbc_for_each_key_value'
|
||||
- 'xbc_node_for_each_array_value'
|
||||
- 'xbc_node_for_each_child'
|
||||
- 'xbc_node_for_each_key_value'
|
||||
- 'zorro_for_each_dev'
|
||||
|
||||
#IncludeBlocks: Preserve # Unknown to clang-format-5.0
|
||||
|
|
2
COPYING
2
COPYING
|
@ -16,3 +16,5 @@ In addition, other licenses may also apply. Please see:
|
|||
Documentation/process/license-rules.rst
|
||||
|
||||
for more details.
|
||||
|
||||
All contributions to the Linux Kernel are subject to this COPYING file.
|
||||
|
|
5
CREDITS
5
CREDITS
|
@ -567,6 +567,11 @@ D: Original author of Amiga FFS filesystem
|
|||
S: Orlando, Florida
|
||||
S: USA
|
||||
|
||||
N: Paul Burton
|
||||
E: paulburton@kernel.org
|
||||
W: https://pburton.com
|
||||
D: MIPS maintainer 2018-2020
|
||||
|
||||
N: Lennert Buytenhek
|
||||
E: kernel@wantstofly.org
|
||||
D: Original (2.4) rewrite of the ethernet bridging code
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -129,7 +129,7 @@ this logic.
|
|||
|
||||
As a single binary will need to support both 48-bit and 52-bit VA
|
||||
spaces, the VMEMMAP must be sized large enough for 52-bit VAs and
|
||||
also must be sized large enought to accommodate a fixed PAGE_OFFSET.
|
||||
also must be sized large enough to accommodate a fixed PAGE_OFFSET.
|
||||
|
||||
Most code in the kernel should not need to consider the VA_BITS, for
|
||||
code that does need to know the VA size the variables are
|
||||
|
|
|
@ -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 |
|
||||
|
|
|
@ -44,8 +44,15 @@ The AArch64 Tagged Address ABI has two stages of relaxation depending
|
|||
how the user addresses are used by the kernel:
|
||||
|
||||
1. User addresses not accessed by the kernel but used for address space
|
||||
management (e.g. ``mmap()``, ``mprotect()``, ``madvise()``). The use
|
||||
of valid tagged pointers in this context is always allowed.
|
||||
management (e.g. ``mprotect()``, ``madvise()``). The use of valid
|
||||
tagged pointers in this context is allowed with the exception of
|
||||
``brk()``, ``mmap()`` and the ``new_address`` argument to
|
||||
``mremap()`` as these have the potential to alias with existing
|
||||
user addresses.
|
||||
|
||||
NOTE: This behaviour changed in v5.6 and so some earlier kernels may
|
||||
incorrectly accept valid tagged pointers for the ``brk()``,
|
||||
``mmap()`` and ``mremap()`` system calls.
|
||||
|
||||
2. User addresses accessed by the kernel (e.g. ``write()``). This ABI
|
||||
relaxation is disabled by default and the application thread needs to
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -43,9 +43,13 @@ properties:
|
|||
- enum:
|
||||
- allwinner,sun8i-h3-tcon-tv
|
||||
- allwinner,sun50i-a64-tcon-tv
|
||||
- allwinner,sun50i-h6-tcon-tv
|
||||
- const: allwinner,sun8i-a83t-tcon-tv
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- allwinner,sun50i-h6-tcon-tv
|
||||
- const: allwinner,sun8i-r40-tcon-tv
|
||||
|
||||
reg:
|
||||
maxItems: 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>;
|
||||
|
|
|
@ -1,9 +1,10 @@
|
|||
Ilitek ILI210x/ILI2117/ILI251x touchscreen controller
|
||||
Ilitek ILI210x/ILI2117/ILI2120/ILI251x touchscreen controller
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
ilitek,ili210x for ILI210x
|
||||
ilitek,ili2117 for ILI2117
|
||||
ilitek,ili2120 for ILI2120
|
||||
ilitek,ili251x for ILI251x
|
||||
|
||||
- reg: The I2C address of the device
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -33,24 +33,40 @@ properties:
|
|||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
minItems: 2
|
||||
maxItems: 3
|
||||
items:
|
||||
- description: The CSI interface clock
|
||||
- description: The CSI ISP clock
|
||||
- description: The CSI DRAM clock
|
||||
oneOf:
|
||||
- items:
|
||||
- description: The CSI interface clock
|
||||
- description: The CSI DRAM clock
|
||||
|
||||
- items:
|
||||
- description: The CSI interface clock
|
||||
- description: The CSI ISP clock
|
||||
- description: The CSI DRAM clock
|
||||
|
||||
clock-names:
|
||||
minItems: 2
|
||||
maxItems: 3
|
||||
items:
|
||||
- const: bus
|
||||
- const: isp
|
||||
- const: ram
|
||||
oneOf:
|
||||
- items:
|
||||
- const: bus
|
||||
- const: ram
|
||||
|
||||
- items:
|
||||
- const: bus
|
||||
- const: isp
|
||||
- const: ram
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
# FIXME: This should be made required eventually once every SoC will
|
||||
# have the MBUS declared.
|
||||
interconnects:
|
||||
maxItems: 1
|
||||
|
||||
# FIXME: This should be made required eventually once every SoC will
|
||||
# have the MBUS declared.
|
||||
interconnect-names:
|
||||
const: dma-mem
|
||||
|
||||
# See ./video-interfaces.txt for details
|
||||
port:
|
||||
type: object
|
||||
|
|
|
@ -177,7 +177,7 @@ examples:
|
|||
};
|
||||
};
|
||||
|
||||
i2c5: i2c@4807c000 {
|
||||
i2c {
|
||||
clock-frequency = <400000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
@ -347,6 +347,7 @@ examples:
|
|||
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
#iommu-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
external-memory-controller@7001b000 {
|
||||
|
@ -363,20 +364,23 @@ examples:
|
|||
timing-0 {
|
||||
clock-frequency = <12750000>;
|
||||
|
||||
nvidia,emc-zcal-cnt-long = <0x00000042>;
|
||||
nvidia,emc-auto-cal-interval = <0x001fffff>;
|
||||
nvidia,emc-ctt-term-ctrl = <0x00000802>;
|
||||
nvidia,emc-cfg = <0x73240000>;
|
||||
nvidia,emc-cfg-2 = <0x000008c5>;
|
||||
nvidia,emc-sel-dpd-ctrl = <0x00040128>;
|
||||
nvidia,emc-bgbias-ctl0 = <0x00000008>;
|
||||
nvidia,emc-auto-cal-config = <0xa1430000>;
|
||||
nvidia,emc-auto-cal-config2 = <0x00000000>;
|
||||
nvidia,emc-auto-cal-config3 = <0x00000000>;
|
||||
nvidia,emc-mode-reset = <0x80001221>;
|
||||
nvidia,emc-auto-cal-interval = <0x001fffff>;
|
||||
nvidia,emc-bgbias-ctl0 = <0x00000008>;
|
||||
nvidia,emc-cfg = <0x73240000>;
|
||||
nvidia,emc-cfg-2 = <0x000008c5>;
|
||||
nvidia,emc-ctt-term-ctrl = <0x00000802>;
|
||||
nvidia,emc-mode-1 = <0x80100003>;
|
||||
nvidia,emc-mode-2 = <0x80200008>;
|
||||
nvidia,emc-mode-4 = <0x00000000>;
|
||||
nvidia,emc-mode-reset = <0x80001221>;
|
||||
nvidia,emc-mrs-wait-cnt = <0x000e000e>;
|
||||
nvidia,emc-sel-dpd-ctrl = <0x00040128>;
|
||||
nvidia,emc-xm2dqspadctrl2 = <0x0130b118>;
|
||||
nvidia,emc-zcal-cnt-long = <0x00000042>;
|
||||
nvidia,emc-zcal-interval = <0x00000000>;
|
||||
|
||||
nvidia,emc-configuration = <
|
||||
0x00000000 /* EMC_RC */
|
||||
|
|
|
@ -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>;
|
||||
|
|
|
@ -124,7 +124,7 @@ not every application needs SDIO irq, e.g. MMC cards.
|
|||
pinctrl-1 = <&mmc1_idle>;
|
||||
pinctrl-2 = <&mmc1_sleep>;
|
||||
...
|
||||
interrupts-extended = <&intc 64 &gpio2 28 GPIO_ACTIVE_LOW>;
|
||||
interrupts-extended = <&intc 64 &gpio2 28 IRQ_TYPE_LEVEL_LOW>;
|
||||
};
|
||||
|
||||
mmc1_idle : pinmux_cirq_pin {
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -56,7 +56,6 @@ patternProperties:
|
|||
examples:
|
||||
- |
|
||||
davinci_mdio: mdio@5c030000 {
|
||||
compatible = "ti,davinci_mdio";
|
||||
reg = <0x5c030000 0x1000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -71,9 +71,13 @@ b) Example for device tree::
|
|||
ipmb@10 {
|
||||
compatible = "ipmb-dev";
|
||||
reg = <0x10>;
|
||||
i2c-protocol;
|
||||
};
|
||||
};
|
||||
|
||||
If xmit of data to be done using raw i2c block vs smbus
|
||||
then "i2c-protocol" needs to be defined as above.
|
||||
|
||||
2) Manually from Linux::
|
||||
|
||||
modprobe ipmb-dev-int
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -134,7 +134,7 @@ Sequential zone files can only be written sequentially, starting from the file
|
|||
end, that is, write operations can only be append writes. Zonefs makes no
|
||||
attempt at accepting random writes and will fail any write request that has a
|
||||
start offset not corresponding to the end of the file, or to the end of the last
|
||||
write issued and still in-flight (for asynchrnous I/O operations).
|
||||
write issued and still in-flight (for asynchronous I/O operations).
|
||||
|
||||
Since dirty page writeback by the page cache does not guarantee a sequential
|
||||
write pattern, zonefs prevents buffered writes and writeable shared mappings
|
||||
|
@ -142,7 +142,7 @@ on sequential files. Only direct I/O writes are accepted for these files.
|
|||
zonefs relies on the sequential delivery of write I/O requests to the device
|
||||
implemented by the block layer elevator. An elevator implementing the sequential
|
||||
write feature for zoned block device (ELEVATOR_F_ZBD_SEQ_WRITE elevator feature)
|
||||
must be used. This type of elevator (e.g. mq-deadline) is the set by default
|
||||
must be used. This type of elevator (e.g. mq-deadline) is set by default
|
||||
for zoned block devices on device initialization.
|
||||
|
||||
There are no restrictions on the type of I/O used for read operations in
|
||||
|
@ -196,7 +196,7 @@ additional conditions that result in I/O errors.
|
|||
may still happen in the case of a partial failure of a very large direct I/O
|
||||
operation split into multiple BIOs/requests or asynchronous I/O operations.
|
||||
If one of the write request within the set of sequential write requests
|
||||
issued to the device fails, all write requests after queued after it will
|
||||
issued to the device fails, all write requests queued after it will
|
||||
become unaligned and fail.
|
||||
|
||||
* Delayed write errors: similarly to regular block devices, if the device side
|
||||
|
@ -207,7 +207,7 @@ additional conditions that result in I/O errors.
|
|||
causing all data to be dropped after the sector that caused the error.
|
||||
|
||||
All I/O errors detected by zonefs are notified to the user with an error code
|
||||
return for the system call that trigered or detected the error. The recovery
|
||||
return for the system call that triggered or detected the error. The recovery
|
||||
actions taken by zonefs in response to I/O errors depend on the I/O type (read
|
||||
vs write) and on the reason for the error (bad sector, unaligned writes or zone
|
||||
condition change).
|
||||
|
@ -222,7 +222,7 @@ condition change).
|
|||
* A zone condition change to read-only or offline also always triggers zonefs
|
||||
I/O error recovery.
|
||||
|
||||
Zonefs minimal I/O error recovery may change a file size and a file access
|
||||
Zonefs minimal I/O error recovery may change a file size and file access
|
||||
permissions.
|
||||
|
||||
* File size changes:
|
||||
|
@ -237,7 +237,7 @@ permissions.
|
|||
A file size may also be reduced to reflect a delayed write error detected on
|
||||
fsync(): in this case, the amount of data effectively written in the zone may
|
||||
be less than originally indicated by the file inode size. After such I/O
|
||||
error, zonefs always fixes a file inode size to reflect the amount of data
|
||||
error, zonefs always fixes the file inode size to reflect the amount of data
|
||||
persistently stored in the file zone.
|
||||
|
||||
* Access permission changes:
|
||||
|
@ -281,11 +281,11 @@ Further notes:
|
|||
permissions to read-only applies to all files. The file system is remounted
|
||||
read-only.
|
||||
* Access permission and file size changes due to the device transitioning zones
|
||||
to the offline condition are permanent. Remounting or reformating the device
|
||||
to the offline condition are permanent. Remounting or reformatting the device
|
||||
with mkfs.zonefs (mkzonefs) will not change back offline zone files to a good
|
||||
state.
|
||||
* File access permission changes to read-only due to the device transitioning
|
||||
zones to the read-only condition are permanent. Remounting or reformating
|
||||
zones to the read-only condition are permanent. Remounting or reformatting
|
||||
the device will not re-enable file write access.
|
||||
* File access permission changes implied by the remount-ro, zone-ro and
|
||||
zone-offline mount options are temporary for zones in a good condition.
|
||||
|
@ -301,13 +301,13 @@ Mount options
|
|||
|
||||
zonefs define the "errors=<behavior>" mount option to allow the user to specify
|
||||
zonefs behavior in response to I/O errors, inode size inconsistencies or zone
|
||||
condition chages. The defined behaviors are as follow:
|
||||
condition changes. The defined behaviors are as follow:
|
||||
* remount-ro (default)
|
||||
* zone-ro
|
||||
* zone-offline
|
||||
* repair
|
||||
|
||||
The I/O error actions defined for each behavior is detailed in the previous
|
||||
The I/O error actions defined for each behavior are detailed in the previous
|
||||
section.
|
||||
|
||||
Zonefs User Space Tools
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -24,6 +24,7 @@ This driver implements support for Infineon Multi-phase XDPE122 family
|
|||
dual loop voltage regulators.
|
||||
The family includes XDPE12284 and XDPE12254 devices.
|
||||
The devices from this family complaint with:
|
||||
|
||||
- Intel VR13 and VR13HC rev 1.3, IMVP8 rev 1.2 and IMPVP9 rev 1.3 DC-DC
|
||||
converter specification.
|
||||
- Intel SVID rev 1.9. protocol.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -244,23 +244,23 @@ disclosure of a particular issue, unless requested by a response team or by
|
|||
an involved disclosed party. The current ambassadors list:
|
||||
|
||||
============= ========================================================
|
||||
ARM
|
||||
ARM Grant Likely <grant.likely@arm.com>
|
||||
AMD Tom Lendacky <tom.lendacky@amd.com>
|
||||
IBM
|
||||
Intel Tony Luck <tony.luck@intel.com>
|
||||
Qualcomm Trilok Soni <tsoni@codeaurora.org>
|
||||
|
||||
Microsoft Sasha Levin <sashal@kernel.org>
|
||||
Microsoft James Morris <jamorris@linux.microsoft.com>
|
||||
VMware
|
||||
Xen Andrew Cooper <andrew.cooper3@citrix.com>
|
||||
|
||||
Canonical Tyler Hicks <tyhicks@canonical.com>
|
||||
Canonical John Johansen <john.johansen@canonical.com>
|
||||
Debian Ben Hutchings <ben@decadent.org.uk>
|
||||
Oracle Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Red Hat Josh Poimboeuf <jpoimboe@redhat.com>
|
||||
SUSE Jiri Kosina <jkosina@suse.cz>
|
||||
|
||||
Amazon Peter Bowen <pzb@amzn.com>
|
||||
Amazon
|
||||
Google Kees Cook <keescook@chromium.org>
|
||||
============= ========================================================
|
||||
|
||||
|
|
|
@ -30,4 +30,4 @@ if [ -n "$parallel" ] ; then
|
|||
parallel="-j$parallel"
|
||||
fi
|
||||
|
||||
exec "$sphinx" "$parallel" "$@"
|
||||
exec "$sphinx" $parallel "$@"
|
||||
|
|
|
@ -183,7 +183,7 @@ CVE分配
|
|||
VMware
|
||||
Xen Andrew Cooper <andrew.cooper3@citrix.com>
|
||||
|
||||
Canonical Tyler Hicks <tyhicks@canonical.com>
|
||||
Canonical John Johansen <john.johansen@canonical.com>
|
||||
Debian Ben Hutchings <ben@decadent.org.uk>
|
||||
Oracle Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Red Hat Josh Poimboeuf <jpoimboe@redhat.com>
|
||||
|
|
|
@ -1,9 +1,11 @@
|
|||
==================
|
||||
Guest halt polling
|
||||
==================
|
||||
|
||||
The cpuidle_haltpoll driver, with the haltpoll governor, allows
|
||||
the guest vcpus to poll for a specified amount of time before
|
||||
halting.
|
||||
|
||||
This provides the following benefits to host side polling:
|
||||
|
||||
1) The POLL flag is set while polling is performed, which allows
|
||||
|
@ -29,18 +31,21 @@ Module Parameters
|
|||
The haltpoll governor has 5 tunable module parameters:
|
||||
|
||||
1) guest_halt_poll_ns:
|
||||
|
||||
Maximum amount of time, in nanoseconds, that polling is
|
||||
performed before halting.
|
||||
|
||||
Default: 200000
|
||||
|
||||
2) guest_halt_poll_shrink:
|
||||
|
||||
Division factor used to shrink per-cpu guest_halt_poll_ns when
|
||||
wakeup event occurs after the global guest_halt_poll_ns.
|
||||
|
||||
Default: 2
|
||||
|
||||
3) guest_halt_poll_grow:
|
||||
|
||||
Multiplication factor used to grow per-cpu guest_halt_poll_ns
|
||||
when event occurs after per-cpu guest_halt_poll_ns
|
||||
but before global guest_halt_poll_ns.
|
||||
|
@ -48,6 +53,7 @@ but before global guest_halt_poll_ns.
|
|||
Default: 2
|
||||
|
||||
4) guest_halt_poll_grow_start:
|
||||
|
||||
The per-cpu guest_halt_poll_ns eventually reaches zero
|
||||
in case of an idle system. This value sets the initial
|
||||
per-cpu guest_halt_poll_ns when growing. This can
|
||||
|
@ -66,7 +72,7 @@ high once achieves global guest_halt_poll_ns value).
|
|||
|
||||
Default: Y
|
||||
|
||||
The module parameters can be set from the debugfs files in:
|
||||
The module parameters can be set from the debugfs files in::
|
||||
|
||||
/sys/module/haltpoll/parameters/
|
||||
|
||||
|
@ -74,5 +80,5 @@ Further Notes
|
|||
=============
|
||||
|
||||
- Care should be taken when setting the guest_halt_poll_ns parameter as a
|
||||
large value has the potential to drive the cpu usage to 100% on a machine which
|
||||
would be almost entirely idle otherwise.
|
||||
large value has the potential to drive the cpu usage to 100% on a machine
|
||||
which would be almost entirely idle otherwise.
|
|
@ -8,7 +8,9 @@ Linux Virtualization Support
|
|||
:maxdepth: 2
|
||||
|
||||
kvm/index
|
||||
uml/user_mode_linux
|
||||
paravirt_ops
|
||||
guest-halt-polling
|
||||
|
||||
.. only:: html and subproject
|
||||
|
||||
|
|
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
|
@ -1,4 +1,8 @@
|
|||
* Internal ABI between the kernel and HYP
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=======================================
|
||||
Internal ABI between the kernel and HYP
|
||||
=======================================
|
||||
|
||||
This file documents the interaction between the Linux kernel and the
|
||||
hypervisor layer when running Linux as a hypervisor (for example
|
||||
|
@ -19,25 +23,31 @@ and only act on individual CPUs.
|
|||
Unless specified otherwise, any built-in hypervisor must implement
|
||||
these functions (see arch/arm{,64}/include/asm/virt.h):
|
||||
|
||||
* r0/x0 = HVC_SET_VECTORS
|
||||
r1/x1 = vectors
|
||||
* ::
|
||||
|
||||
r0/x0 = HVC_SET_VECTORS
|
||||
r1/x1 = vectors
|
||||
|
||||
Set HVBAR/VBAR_EL2 to 'vectors' to enable a hypervisor. 'vectors'
|
||||
must be a physical address, and respect the alignment requirements
|
||||
of the architecture. Only implemented by the initial stubs, not by
|
||||
Linux hypervisors.
|
||||
|
||||
* r0/x0 = HVC_RESET_VECTORS
|
||||
* ::
|
||||
|
||||
r0/x0 = HVC_RESET_VECTORS
|
||||
|
||||
Turn HYP/EL2 MMU off, and reset HVBAR/VBAR_EL2 to the initials
|
||||
stubs' exception vector value. This effectively disables an existing
|
||||
hypervisor.
|
||||
|
||||
* r0/x0 = HVC_SOFT_RESTART
|
||||
r1/x1 = restart address
|
||||
x2 = x0's value when entering the next payload (arm64)
|
||||
x3 = x1's value when entering the next payload (arm64)
|
||||
x4 = x2's value when entering the next payload (arm64)
|
||||
* ::
|
||||
|
||||
r0/x0 = HVC_SOFT_RESTART
|
||||
r1/x1 = restart address
|
||||
x2 = x0's value when entering the next payload (arm64)
|
||||
x3 = x1's value when entering the next payload (arm64)
|
||||
x4 = x2's value when entering the next payload (arm64)
|
||||
|
||||
Mask all exceptions, disable the MMU, move the arguments into place
|
||||
(arm64 only), and jump to the restart address while at HYP/EL2. This
|
|
@ -0,0 +1,12 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===
|
||||
ARM
|
||||
===
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
hyp-abi
|
||||
psci
|
||||
pvtime
|
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче