| /Documentation/scheduler/ |
| D | sched-stats.rst | 7 columns in show_schedstat(). In particular the position of CPU_IDLE
15 mainline kernel in 2.6.20 although it is identical to the stats from version
16 12 which was in the kernel from 2.6.13-2.6.19 (version 13 never saw a kernel
21 In version 14 of schedstat, there is at least one level of domain
23 domain. Domains have no particular names in this implementation, but
28 field in the domain stats is a bit map indicating which cpus are affected
33 the change in the counters at each subsequent observation. A perl script
39 reason to change versions is changes in the output format. For those wishing
52 2) This field is a legacy array expiration count field used in the O(1)
64 7) sum of all time spent running by tasks on this processor (in nanoseconds)
[all …]
|
| /Documentation/virt/hyperv/ |
| D | coco.rst | 7 the confidentiality and integrity of data in the VM's memory, even in the
10 objectives described in Documentation/security/snp-tdx-threat-model.rst. Note
11 that Hyper-V specific code in Linux refers to CoCo VMs as "isolated VMs" or
37 Hyper-V CoCo VMs can run in two modes. The mode is selected when the VM is
40 * Fully-enlightened mode. In this mode, the guest operating system is
43 * Paravisor mode. In this mode, a paravisor layer between the guest and the
45 system can have fewer CoCo enlightenments than is required in the
55 does not go this far, and is somewhere in the middle of the spectrum. Some
58 standardized enumeration of feature/functions that might be provided in the
61 the paravisor provides is hard-coded in the guest OS.
[all …]
|
| D | overview.rst | 8 management service running in the parent partition (roughly
9 equivalent to KVM and QEMU, for example). Guest VMs run in child
10 partitions. In this documentation, references to Hyper-V usually
21 Linux guests communicate with Hyper-V in four different ways:
30 and returns control to the caller. Parameters are passed in
31 processor registers or in memory shared between the Linux guest and
37 synthetic registers. On x86/x64 these registers appear as MSRs in
49 The first three communication mechanisms are documented in the
73 GPAs, which usually do not need to be contiguous in the guest
75 of GPAs varies. In some cases, a single GPA is written to a
[all …]
|
| /Documentation/hwmon/ |
| D | lt7182s.rst | 38 It can also be instantiated by declaring an entry in device tree.
56 in[1-2]_label "vin[12]"
57 in[1-2]_input Measured input voltage
58 in[1-2]_highest Highest measured input voltage
59 in[1-2]_crit Critical maximum input voltage
60 in[1-2]_crit_alarm Input voltage critical high alarm
61 in[1-2]_min Minimum input voltage
62 in[1-2]_min_alarm Input voltage low alarm
63 in[1-2]_rated_min Rated minimum input voltage
64 in[1-2]_rated_max Rated maximum input voltage
[all …]
|
| /Documentation/filesystems/ |
| D | idmappings.rst | 16 in userspace is::
20 ``u`` indicates the first element in the upper idmapset ``U`` and ``k``
21 indicates the first element in the lower idmapset ``K``. The ``r`` parameter
24 we're talking about an id in the upper or lower idmapset.
26 To see what this looks like in practice, let's take the following idmapping::
38 order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of
59 ``u1000`` from the upper idmapset down to ``k11000`` in the lower idmapset.
62 what id ``k11000`` corresponds to in the second or third idmapping. The
78 contain ``u1000`` in the upper idmapset ``U``. This is equivalent to not having
79 an id mapped. We can simply say that ``u1000`` is unmapped in the second and
[all …]
|
| /Documentation/userspace-api/media/v4l/ |
| D | pixfmt-intro.rst | 7 In order to exchange images between drivers and applications, it is
11 image data formats in V4L2.
14 formats are possible. In that case the application may depend on a codec
16 data can still be stored and retrieved in the proprietary format. For
18 Applications can still capture and save the data in the compressed
27 are always arranged in memory from left to right, and from top to
28 bottom. The first byte of data in the image buffer is always for the
37 In V4L2 each format has an identifier which looks like ``PIX_FMT_XXX``,
38 defined in the :ref:`videodev2.h <videodev>` header file. These
41 listed below, however they are not the same as those used in the Windows
[all …]
|
| /Documentation/firmware-guide/acpi/ |
| D | DSD-properties-rules.rst | 10 The _DSD (Device Specific Data) configuration object, introduced in ACPI 5.1,
12 namespace. In principle, the format of the data may be arbitrary, but it has to
15 the ACPI subsystem in the Linux kernel which automatically processes the data
22 In the ACPI _DSD context it is an element of the sub-package following the
23 generic Device Properties UUID in the _DSD return package as specified in the
25 "Device Properties UUID" in _DSD (Device Specific Data) Implementation Guide
29 that can be returned by _DSD in the Device Properties UUID sub-package for a
33 like a device. In the ACPI _DSD context it is the set of all properties that
34 can be returned in the Device Properties UUID sub-package for the device in
40 representation of property subsets is via the mechanism specified in the
[all …]
|
| /Documentation/admin-guide/ |
| D | sysfs-rules.rst | 1 Rules on how to access information in sysfs
10 To minimize the risk of breaking users of sysfs, which are in most cases
24 implementation details in its own API. Therefore it is not better than
26 Also, it is not actively maintained, in the sense of reflecting the
29 violates many of the rules in this document.
40 interfaces, and such that you can rely on in userspace. Everything is
43 applications that look for devices in sysfs.
49 - identical to the DEVPATH value in the event sent from the kernel
51 - the unique key to the device at that point in time
59 - using or exposing symlink values as elements in a devpath string
[all …]
|
| /Documentation/networking/ |
| D | checksum-offloads.rst | 11 This document describes a set of techniques in the Linux networking stack to
29 The interface for offloading a transmit checksum to a device is explained in
30 detail in comments near the top of include/linux/skbuff.h.
32 In brief, it allows to request the device fill in a single ones-complement
35 'IP-style' checksum) from csum_start to the end of the packet, and fill in the
39 the checksum field is included in the checksum computation, thus it can be used
44 encapsulation is used, the packet may have multiple checksum fields in
52 No offloading of the IP header checksum is performed; it is always done in
54 in cache, so summing it isn't expensive. It's also rather short.
61 A driver declares its offload capabilities in netdev->hw_features; see
[all …]
|
| D | strparser.rst | 12 parser works in conjunction with an upper layer in the kernel to provide
17 The strparser works in one of two modes: receive callback or general
20 In receive callback mode, the strparser is called from the data_ready
24 In general mode, a sequence of skbs are fed to strparser from an
35 parsing (e.g. BPF parsing in case of KCM), and a rcv_msg function
49 callback mode; in general mode this is set to NULL. Callbacks
88 strp_process is called in general mode for a stream parser to
122 in the stream. The upper layer must implement this function. It
124 next application layer message in the stream.
126 The skb->cb in the input skb is a struct strp_msg. Only
[all …]
|
| /Documentation/kbuild/ |
| D | kconfig-macro-language.rst | 9 two languages in one. One language describes dependency graphs consisting of
32 The idea is quite similar in Kconfig - it is possible to describe a Kconfig
40 The macro language in Kconfig processes the source file into the following
47 dependency as explained in kconfig-language.rst.
53 Like in Make, a variable in Kconfig works as a macro variable. A macro
54 variable is expanded "in place" to yield a text string that may then be
55 expanded further. To get the value of a variable, enclose the variable name in
57 a syntax error. The curly brace form as in ${CC} is not supported either.
68 expanding it in any way. Instead, the expansion is performed when the variable
76 The variable reference can take parameters, in the following form::
[all …]
|
| /Documentation/devicetree/bindings/riscv/ |
| D | extensions.yaml | 21 Once a standard extension has been ratified, no changes in behaviour can be
37 supported by the hart. These are documented in the RISC-V
47 While the isa strings in ISA specification are case
48 insensitive, letters in the riscv,isa string must be all
68 # single letter extensions, in canonical order
71 The base integer instruction set, as ratified in the 20191213
81 ratified in the 20191213 version of the unprivileged ISA
86 The standard A extension for atomic instructions, as ratified in the
92 ratified in the 20191213 version of the unprivileged ISA
98 ratified in the 20191213 version of the unprivileged ISA
[all …]
|
| /Documentation/admin-guide/pm/ |
| D | strategies.rst | 15 One of them is based on using global low-power states of the whole system in
19 and the system stays in it until a special signal is received from one of
20 designated devices, triggering a transition to the ``working state`` in which
27 components of the system, as needed, in the working state. In consequence, if
28 this strategy is in use, the working state of the system usually does not
30 a metastate covering a range of different power states of the system in which
31 the individual components of it can be either ``active`` (in use) or
32 ``inactive`` (idle). If they are active, they have to be in power states
33 allowing them to process data and to be accessed by software. In turn, if they
34 are inactive, ideally, they should be in low-power states in which they may not
[all …]
|
| D | cpuidle.rst | 19 Modern processors are generally able to enter states in which the execution of
23 Since part of the processor hardware is not used in idle states, entering them
24 generally allows power drawn by the processor to be reduced and, in consequence,
35 work in the system). In its view, CPUs are *logical* units. That is, they need
37 software as individual single-core processors. In other words, a CPU is an
43 program) at a time, it is a CPU. In that case, if the hardware is asked to
46 Second, if the processor is multi-core, each core in it is able to follow at
49 work physically in parallel with each other, so if each of them executes only
51 time. The entire cores are CPUs in that case and if the hardware is asked to
52 enter an idle state, that applies to the core that asked for it in the first
[all …]
|
| /Documentation/arch/riscv/ |
| D | hwprobe.rst | 7 is defined in <asm/hwprobe.h>::
20 must prepopulate the key field for each element, and the kernel will fill in the
24 arch, impl), the returned value will only be valid if all CPUs in the given set
67 programs (it may still be executed in userspace via a
85 supported, as defined in version 1.0 of the Bit-Manipulation ISA
89 in version 1.0 of the Bit-Manipulation ISA extensions.
92 in version 1.0 of the Bit-Manipulation ISA extensions.
95 ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
98 in version 1.0 of the Bit-Manipulation ISA extensions.
101 defined in version 1.0 of the Scalar Crypto ISA extensions.
[all …]
|
| /Documentation/devicetree/bindings/memory-controllers/ddr/ |
| D | jedec,lpddr3-timings.yaml | 19 Maximum DDR clock frequency for the speed-bin, in Hz.
26 Maximum DDR clock frequency for the speed-bin, in Hz.
31 Minimum DDR clock frequency for the speed-bin, in Hz.
36 CKE minimum pulse width (HIGH and LOW pulse width) in pico seconds.
42 SELF REFRESH) in pico seconds.
47 Four-bank activate window in pico seconds.
52 Mode register set command delay in pico seconds.
57 Additional READ-to-READ delay in chip-to-chip cases in pico seconds.
62 Row active time in pico seconds.
67 ACTIVATE-to-ACTIVATE command period in pico seconds.
[all …]
|
| /Documentation/security/keys/ |
| D | ecryptfs.rst | 8 Each FEK is in turn encrypted with a File Encryption Key Encryption Key (FEKEK)
9 either in kernel space or in user space with a daemon called 'ecryptfsd'. In
11 using a key, the FEKEK, derived from a user prompted passphrase; in the latter
12 the FEK is encrypted by 'ecryptfsd' with the help of external libraries in order
17 FEK decryption is called authentication token and, currently, can be stored in a
18 kernel key of the 'user' type, inserted in the user's session specific keyring
23 format 'ecryptfs' in order to be used in conjunction with the eCryptfs
25 authentication token in its payload with a FEKEK randomly generated by the
28 In order to avoid known-plaintext attacks, the datablob obtained through
30 authentication token, which content is well known, but only the FEKEK in
[all …]
|
| /Documentation/admin-guide/mm/ |
| D | userfaultfd.rst | 20 region(s) result in a message being delivered to the userfaultfd, notifying
30 registered in the ``userfaultfd`` that allows userland to efficiently
32 memory in the background
35 management of mremap/mprotect is that the userfaults in all their
36 operations never involve heavyweight structures like vmas (in fact the
61 userfaultfd(2) syscall. Access to this is controlled in several ways:
67 - In order to also trap kernel page faults for the address space, either the
102 other than page faults are supported. These events are described in more
103 detail below in the `Non-cooperative userfaultfd`_ section.
124 ioctl should be invoked (if present in the returned ``uffdio_api.ioctls``
[all …]
|
| /Documentation/networking/device_drivers/ethernet/altera/ |
| D | altera_tse.rst | 22 the maintainer of this driver, found in MAINTAINERS.
36 The SGDMA component is to be deprecated in the near future (over the next 1-2
37 years as of this writing in early 2014) in favor of the MSGDMA component.
38 SGDMA support is included for existing designs and reference in case a
53 tested for 1Gbps. This support will be added in a future maintenance update.
67 - dma_rx_num: Number of descriptors in the RX list (default is 64);
68 - dma_tx_num: Number of descriptors in the TX list (default is 64).
73 Driver parameters can be also passed in command line by using::
86 completion in the context of the interrupt handling chain by recycling
103 for transmit operations, but will be added in a future maintenance release.
[all …]
|
| /Documentation/arch/powerpc/ |
| D | booting.rst | 9 bootloader <-> kernel interfaces, in order to avoid the degeneration that had
12 this scheme, but no new board support will be accepted in the main tree that
13 doesn't follow them properly. In addition, since the advent of the arch/powerpc
18 The main requirement that will be defined in more detail below is the presence
20 However, in order to make life easier to embedded board vendors, the kernel
21 doesn't require the device-tree to represent every device in the system and only
23 not require you to create a node for every PCI device in the system. It is a
24 requirement to have a node for PCI host bridges in order to provide interrupt
27 in an existing OF specification. This creates a great flexibility in the way the
53 trampoline located in arch/powerpc/kernel/prom_init.c to
[all …]
|
| /Documentation/arch/arm/ |
| D | booting.rst | 11 In order to boot ARM Linux, you require a boot loader, which is a small
36 kernel will use for volatile data storage in the system. It performs
37 this in a machine dependent manner. (It may use internal algorithms
39 the RAM in the machine, or any other method the boot loader designer
58 serial format options as described in
76 should be passed to the kernel in register r1.
92 boot data is passed to the kernel in register r2.
103 Any number of tags can be placed in the list. It is undefined
105 previous tag, or whether it replaces the information in its
120 The tagged list should be stored in system RAM.
[all …]
|
| D | cluster-pm-race-avoidance.rst | 12 algorithm in use.
18 In a system containing multiple CPUs, it is desirable to have the
22 In a system containing multiple clusters of CPUs, it is also desirable
28 means that we need some coordination in order to ensure that critical
37 methods of coordination are required in order to guarantee safe
40 The mechanism presented in this document describes a coherent memory
77 level. A CPU in this state is not necessarily being used
86 Each CPU has one of these states assigned to it at any point in time.
87 The CPU states are described in the "CPU state" section, below.
91 to introduce additional states in order to avoid races between different
[all …]
|
| /Documentation/sound/designs/ |
| D | tracepoints.rst | 2 Tracepoints in ALSA
8 Tracepoints in ALSA PCM core
30 In a design of ALSA PCM core, data transmission is abstracted as PCM substream.
33 substream. In this procedure, PCM hardware parameters are decided by
37 The parameters are described in struct snd_pcm_hw_params. This
49 Configurable. This type of parameter is described in
57 Configurable. This type of parameter is described in
80 Read-only. After returning from ioctl(2), buffer in user space for
90 Read-only. This value represents available bit width in MSB side of
93 it. Else, zero. But this behaviour depends on implementations in driver
[all …]
|
| /Documentation/ABI/ |
| D | README | 4 interfaces should be used by userspace programs in different ways.
7 different subdirectories in this location. Interfaces may change levels
25 errors or security problems are found in them. Userspace
35 This directory documents interfaces that are still remaining in
36 the kernel, but are marked to be removed at some later point in
44 Every file in these directories will contain the following information:
48 KernelVersion: Kernel version this feature first showed up in.
52 it changes. This is very important for interfaces in
55 break in ways that are unacceptable. It is also
57 sure they are working in a proper way and do not need to
[all …]
|
| /Documentation/devicetree/bindings/sound/ |
| D | mt2701-cs42448.txt | 11 - i2s1-in-sel-gpio1, i2s1-in-sel-gpio2: Should specify two gpio pins to
12 control I2S1-in mux.
31 "AIN2L", "Tuner In",
32 "AIN2R", "Tuner In",
33 "AIN3L", "Satellite Tuner In",
34 "AIN3R", "Satellite Tuner In",
35 "AIN3L", "AUX In",
36 "AIN3R", "AUX In";
41 i2s1-in-sel-gpio1 = <&pio 53 0>;
42 i2s1-in-sel-gpio2 = <&pio 54 0>;
|