mirror of
https://github.com/torvalds/linux.git
synced 2024-11-23 12:42:02 +00:00
Linux 5.6
-----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAl6BIG4eHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGlHUH/RCFve2sfHRPjRW+ xR5SaLVAw6XKvtKBq7yvKmHEwqNJnL79IHyqqtSrtfFr2FfaH/KvYiCbbAezvSrM np0udGu7STKGd21CWuyEZJudyhXkOwMRNiFiCXWp7rs35oh8T0TpJxMzo2Nc1nLk JFQPqAP6OSvq4IkWEywKQI+Au3Z1IBf83xVjZ1s+MKPQHYD49x2hc4cQntL5/cnm a3DoR2iBkYiGZCZ9dDqAqJTnMQIiCbACdZXgGjNRUpdyA/dtAjsMl11NPYHm8TA2 3AHBupAK50WBZGad6xv2qKQyScsmoJG2mv92QjlOFz0Tpiu6rLnDlLYREDVB6YH6 qbLDsc8= =XEIU -----END PGP SIGNATURE----- Merge tag 'v5.6' into mips-next Linux 5.6
This commit is contained in:
commit
ba15533275
@ -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
|
||||
|
1
.mailmap
1
.mailmap
@ -225,6 +225,7 @@ Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
|
||||
Praveen BP <praveenbp@ti.com>
|
||||
Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com>
|
||||
Qais Yousef <qsyousef@gmail.com> <qais.yousef@imgtec.com>
|
||||
Quentin Monnet <quentin@isovalent.com> <quentin.monnet@netronome.com>
|
||||
Quentin Perret <qperret@qperret.net> <quentin.perret@arm.com>
|
||||
Rafael J. Wysocki <rjw@rjwysocki.net> <rjw@sisk.pl>
|
||||
Rajesh Shah <rajesh.shah@intel.com>
|
||||
|
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.
|
||||
|
@ -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
|
||||
|
@ -23,6 +23,8 @@ properties:
|
||||
- items:
|
||||
- const: allwinner,sun7i-a20-crypto
|
||||
- const: allwinner,sun4i-a10-crypto
|
||||
- items:
|
||||
- const: allwinner,sun8i-a33-crypto
|
||||
|
||||
reg:
|
||||
maxItems: 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>;
|
||||
|
@ -5,6 +5,7 @@ Required properties:
|
||||
* "cypress,tm2-touchkey" - for the touchkey found on the tm2 board
|
||||
* "cypress,midas-touchkey" - for the touchkey found on midas boards
|
||||
* "cypress,aries-touchkey" - for the touchkey found on aries boards
|
||||
* "coreriver,tc360-touchkey" - for the Coreriver TouchCore 360 touchkey
|
||||
- reg: I2C address of the chip.
|
||||
- interrupts: interrupt to which the chip is connected (see interrupt
|
||||
binding[0]).
|
||||
|
@ -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>,
|
||||
|
@ -205,6 +205,8 @@ patternProperties:
|
||||
description: Colorful GRP, Shenzhen Xueyushi Technology Ltd.
|
||||
"^compulab,.*":
|
||||
description: CompuLab Ltd.
|
||||
"^coreriver,.*":
|
||||
description: CORERIVER Semiconductor Co.,Ltd.
|
||||
"^corpro,.*":
|
||||
description: Chengdu Corpro Technology Co., Ltd.
|
||||
"^cortina,.*":
|
||||
|
@ -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
|
||||
|
||||
|
@ -266,11 +266,15 @@ to use.
|
||||
attached (via the dmaengine_desc_attach_metadata() helper to the descriptor.
|
||||
|
||||
From the DMA driver the following is expected for this mode:
|
||||
|
||||
- DMA_MEM_TO_DEV / DEV_MEM_TO_MEM
|
||||
|
||||
The data from the provided metadata buffer should be prepared for the DMA
|
||||
controller to be sent alongside of the payload data. Either by copying to a
|
||||
hardware descriptor, or highly coupled packet.
|
||||
|
||||
- DMA_DEV_TO_MEM
|
||||
|
||||
On transfer completion the DMA driver must copy the metadata to the client
|
||||
provided metadata buffer before notifying the client about the completion.
|
||||
After the transfer completion, DMA drivers must not touch the metadata
|
||||
@ -284,10 +288,14 @@ to use.
|
||||
and dmaengine_desc_set_metadata_len() is provided as helper functions.
|
||||
|
||||
From the DMA driver the following is expected for this mode:
|
||||
- get_metadata_ptr
|
||||
|
||||
- get_metadata_ptr()
|
||||
|
||||
Should return a pointer for the metadata buffer, the maximum size of the
|
||||
metadata buffer and the currently used / valid (if any) bytes in the buffer.
|
||||
- set_metadata_len
|
||||
|
||||
- set_metadata_len()
|
||||
|
||||
It is called by the clients after it have placed the metadata to the buffer
|
||||
to let the DMA driver know the number of valid bytes provided.
|
||||
|
||||
|
@ -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:
|
||||
@ -258,11 +258,11 @@ conditions.
|
||||
| option | condition | size read write read write |
|
||||
+--------------+-----------+-----------------------------------------+
|
||||
| | good | fixed yes no yes yes |
|
||||
| remount-ro | read-only | fixed yes no yes no |
|
||||
| remount-ro | read-only | as is yes no yes no |
|
||||
| (default) | offline | 0 no no no no |
|
||||
+--------------+-----------+-----------------------------------------+
|
||||
| | good | fixed yes no yes yes |
|
||||
| zone-ro | read-only | fixed yes no yes no |
|
||||
| zone-ro | read-only | as is yes no yes no |
|
||||
| | offline | 0 no no no no |
|
||||
+--------------+-----------+-----------------------------------------+
|
||||
| | good | 0 no no yes yes |
|
||||
@ -270,7 +270,7 @@ conditions.
|
||||
| | offline | 0 no no no no |
|
||||
+--------------+-----------+-----------------------------------------+
|
||||
| | good | fixed yes yes yes yes |
|
||||
| repair | read-only | fixed yes no yes no |
|
||||
| repair | read-only | as is yes no yes no |
|
||||
| | offline | 0 no no no no |
|
||||
+--------------+-----------+-----------------------------------------+
|
||||
|
||||
@ -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,14 +301,22 @@ 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
|
||||
section.
|
||||
The run-time I/O error actions defined for each behavior are detailed in the
|
||||
previous section. Mount time I/O errors will cause the mount operation to fail.
|
||||
The handling of read-only zones also differs between mount-time and run-time.
|
||||
If a read-only zone is found at mount time, the zone is always treated in the
|
||||
same manner as offline zones, that is, all accesses are disabled and the zone
|
||||
file size set to 0. This is necessary as the write pointer of read-only zones
|
||||
is defined as invalib by the ZBC and ZAC standards, making it impossible to
|
||||
discover the amount of data that has been written to the zone. In the case of a
|
||||
read-only zone discovered at run-time, as indicated in the previous section.
|
||||
the size of the zone file is left unchanged from its last updated value.
|
||||
|
||||
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>
|
||||
|
@ -53,6 +53,29 @@ key management interface to perform common hypervisor activities such as
|
||||
encrypting bootstrap code, snapshot, migrating and debugging the guest. For more
|
||||
information, see the SEV Key Management spec [api-spec]_
|
||||
|
||||
The main ioctl to access SEV is KVM_MEM_ENCRYPT_OP. If the argument
|
||||
to KVM_MEM_ENCRYPT_OP is NULL, the ioctl returns 0 if SEV is enabled
|
||||
and ``ENOTTY` if it is disabled (on some older versions of Linux,
|
||||
the ioctl runs normally even with a NULL argument, and therefore will
|
||||
likely return ``EFAULT``). If non-NULL, the argument to KVM_MEM_ENCRYPT_OP
|
||||
must be a struct kvm_sev_cmd::
|
||||
|
||||
struct kvm_sev_cmd {
|
||||
__u32 id;
|
||||
__u64 data;
|
||||
__u32 error;
|
||||
__u32 sev_fd;
|
||||
};
|
||||
|
||||
|
||||
The ``id`` field contains the subcommand, and the ``data`` field points to
|
||||
another struct containing arguments specific to command. The ``sev_fd``
|
||||
should point to a file descriptor that is opened on the ``/dev/sev``
|
||||
device, if needed (see individual commands).
|
||||
|
||||
On output, ``error`` is zero on success, or an error code. Error codes
|
||||
are defined in ``<linux/psp-dev.h>`.
|
||||
|
||||
KVM implements the following commands to support common lifecycle events of SEV
|
||||
guests, such as launching, running, snapshotting, migrating and decommissioning.
|
||||
|
||||
@ -90,6 +113,8 @@ Returns: 0 on success, -negative on error
|
||||
|
||||
On success, the 'handle' field contains a new handle and on error, a negative value.
|
||||
|
||||
KVM_SEV_LAUNCH_START requires the ``sev_fd`` field to be valid.
|
||||
|
||||
For more details, see SEV spec Section 6.2.
|
||||
|
||||
3. KVM_SEV_LAUNCH_UPDATE_DATA
|
||||
|
@ -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
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user