| /Documentation/devicetree/bindings/clock/ |
| D | fsl,imx8-acm.yaml | 35 for the full list of i.MX8 ACM clock IDs.
64 - description: power domain of IMX_SC_R_AUDIO_CLK_0
65 - description: power domain of IMX_SC_R_AUDIO_CLK_1
66 - description: power domain of IMX_SC_R_MCLK_OUT_0
67 - description: power domain of IMX_SC_R_MCLK_OUT_1
68 - description: power domain of IMX_SC_R_AUDIO_PLL_0
69 - description: power domain of IMX_SC_R_AUDIO_PLL_1
70 - description: power domain of IMX_SC_R_ASRC_0
71 - description: power domain of IMX_SC_R_ASRC_1
72 - description: power domain of IMX_SC_R_ESAI_0
[all …]
|
| /Documentation/filesystems/ |
| D | directory-locking.rst | 7 kinds of locks - per-inode (->i_rwsem) and per-filesystem
44 * decide which of the source and target need to be locked.
58 ancestor of the other, lock the parent of source first.
60 * verify that the source is not a descendent of the target and
61 target is not a descendent of source; fail the operation otherwise.
73 in its own right; it may happen as part of lookup. We speak of the
75 picture of those - especially for network filesystems. What we have
76 is a bunch of subtrees visible in dcache and locking happens on those.
79 when one growing tree reaches the root of another? That can happen in
81 from the same NFS4 server and doing lookups in one of them has reached
[all …]
|
| /Documentation/sound/designs/ |
| D | tracepoints.rst | 12 This subsystem includes two categories of tracepoints; for state of PCM buffer
13 and for processing of PCM hardware parameters. These tracepoints are available
18 Tracepoints for state of PCM buffer
24 Tracepoints for processing of PCM hardware parameters
30 In a design of ALSA PCM core, data transmission is abstracted as PCM substream.
34 interaction between applications and ALSA PCM core. Once decided, runtime of
38 structure includes several types of parameters. Applications set preferable
41 set of parameters. The latter is used for an actual decision of the parameters.
49 Configurable. This type of parameter is described in
50 struct snd_mask and represent mask values. As of PCM protocol
[all …]
|
| /Documentation/process/ |
| D | code-of-conduct-interpretation.rst | 3 Linux Kernel Contributor Covenant Code of Conduct Interpretation
7 provide a set of rules for almost any open source community. Every
9 Because of this, this document describes how we in the Linux kernel
14 to "traditional" ways of developing software. Your contributions and
19 the best possible solution for the overall success of Linux. This
22 quality of submission and eventual result to ever decrease.
27 The Code of Conduct uses the term "maintainers" numerous times. In the
35 The Code of Conduct mentions rights and responsibilities for
43 behave in the parts of the community where they are active. That
44 responsibility is upon all of us, and ultimately the Code of Conduct
[all …]
|
| D | 1.Intro.rst | 9 The rest of this section covers the scope of the kernel development process
10 and the kinds of frustrations that developers and their employers can
14 influence the direction of kernel development. Code contributed to the
18 release cycle, and the mechanics of the merge window. The various phases in
20 discussion of tools and mailing lists. Developers wanting to get started
29 patches are covered, and there is an introduction to some of the tools
32 :ref:`development_posting` talks about the process of posting patches for
40 of the development process; this section offers a number of tips on how to
44 :ref:`development_advancedtopics` introduces a couple of "advanced" topics:
53 The Linux kernel, at over 8 million lines of code and well over 1000
[all …]
|
| D | 4.Coding.rst | 7 process, the proof of any kernel development project is in the resulting
9 (or not) into the mainline tree. So it is the quality of this code which
10 will determine the ultimate success of the project.
13 number of ways in which kernel developers can go wrong. Then the focus
25 :ref:`Documentation/process/coding-style.rst <codingstyle>`. For much of
27 advisory. As a result, there is a substantial amount of code in the kernel
28 which does not meet the coding style guidelines. The presence of that code
31 The first of these is to believe that the kernel coding standards do not
32 matter and are not enforced. The truth of the matter is that adding new
36 requires some uniformity of code to make it possible for developers to
[all …]
|
| D | cve.rst | 9 in inappropriate ways and for inappropriate reasons. Because of this,
11 combination of continuing pressure to assign CVEs and other forms of
13 outside of the kernel community has made it clear that the kernel
18 of the :doc:`normal Linux kernel security bug reporting
21 A list of all assigned CVEs for the Linux kernel can be found in the
22 archives of the linux-cve mailing list, as seen on
23 https://lore.kernel.org/linux-cve-announce/. To get notice of the
30 As part of the normal stable release process, kernel changes that are
37 any bug might be exploitable to compromise the security of the kernel,
38 but the possibility of exploitation is often not evident when the bug is
[all …]
|
| /Documentation/admin-guide/ |
| D | iostats.rst | 16 is mounted on ``/sys``, although of course it may be mounted anywhere.
20 Here are examples of these different formats::
38 a choice of ``cat /sys/block/hda/stat`` or ``grep 'hda ' /proc/diskstats``.
40 The advantage of one over the other is that the sysfs choice works well
41 if you are watching a known, small set of disks. ``/proc/diskstats`` may
42 be a better choice if you are watching a large number of disks because
43 you'll avoid the overhead of 50, 100, or 500 or more opens/closes with
44 each snapshot of your disk statistics.
47 the above example, the first field of statistics would be 446216.
51 minor device numbers, and device name. Each of these formats provides
[all …]
|
| /Documentation/scheduler/ |
| D | sched-stats.rst | 5 Version 16 of schedstats changed the order of definitions within
6 'enum cpu_idle_type', which changed the order of [CPU_MAX_IDLE_TYPES]
7 columns in show_schedstat(). In particular the position of CPU_IDLE
8 and __CPU_NOT_IDLE changed places. The size of the array is unchanged.
10 Version 15 of schedstats dropped counters for some sched_yield:
14 Version 14 of schedstats includes support for sched_domains, which hit the
21 In version 14 of schedstat, there is at least one level of domain
26 sometimes balancing only between pairs of cpus. At this time, there
32 of these will need to start with a baseline observation and then calculate
34 which does this for many of the fields is available at
[all …]
|
| /Documentation/admin-guide/perf/ |
| D | hns3-pmu.rst | 6 End Point device to collect performance statistics of HiSilicon SoC NIC.
9 HNS3 PMU supports collection of performance statistics such as bandwidth,
17 The HNS3 PMU driver registers a perf PMU with the name of its sicl id.::
21 PMU driver provides description of available events, filter modes, format,
24 The "events" directory describes the event code of all supported events
27 The "filtermode" directory describes the supported filter modes of each
30 The "format" directory describes all formats of the config (events) and
31 config1 (filter options) fields of the perf_event_attr structure.
33 The "identifier" file shows version of PMU hardware device.
35 The "bdf_min" and "bdf_max" files show the supported bdf range of each
[all …]
|
| /Documentation/userspace-api/media/ |
| D | fdl-appendix.rst | 15 The purpose of this License is to make a manual, textbook, or other
16 written document "free" in the sense of freedom: to assure everyone the
23 This License is a kind of "copyleft", which means that derivative works
24 of the document must themselves be free in the same sense. It
32 used for any textual work, regardless of subject matter or whether it is
47 terms of this License. The "Document", below, refers to any such manual
48 or work. Any member of the public is a licensee, and is addressed as
54 A "Modified Version" of the Document means any work containing the
55 Document or a portion of it, either copied verbatim, or with
61 A "Secondary Section" is a named appendix or a front-matter section of
[all …]
|
| /Documentation/networking/device_drivers/ethernet/mellanox/mlx5/ |
| D | counters.rst | 22 addition, each group of counters may have different counter types.
71 An aggregation of software ring counters.
86 A set of the physical port counters, per priority per port.
105 Increment of these counters might indicate a problem. Each of these counters
119 explicitly documented since `tx[i]_packets` describes the behavior of both
127 These counters provide information on the amount of traffic that was accelerated
145 - The number of packets received on ring i.
149 - The number of bytes received on ring i.
153 - The number of packets transmitted on ring i.
157 - The number of bytes transmitted on ring i.
[all …]
|
| /Documentation/admin-guide/mm/ |
| D | hugetlbpage.rst | 8 The intent of this file is to give a brief summary of hugetlbpage support in
9 the Linux kernel. This support is built on top of multiple page size support
13 256M and ppc64 supports 4K and 16M. A TLB is a cache of virtual-to-physical
15 Operating systems try to make best use of limited number of TLB resources.
27 The ``/proc/meminfo`` file provides information about the total number of
29 default huge page size and information about the number of free, reserved
30 and surplus huge pages in the pool of huge pages of default size.
32 size of the arguments to system calls that map huge page regions.
34 The output of ``cat /proc/meminfo`` will include lines like::
46 is the size of the pool of huge pages.
[all …]
|
| /Documentation/input/ |
| D | multi-touch-protocol.rst | 13 In order to utilize the full power of the new multi-touch and multi-user
17 drivers to report details for an arbitrary number of contacts.
19 The protocol is divided into two types, depending on the capabilities of the
22 devices capable of tracking identifiable contacts (type B), the protocol
32 Contact details are sent sequentially as separate packets of ABS_MT
33 events. Only the ABS_MT events are recognized as part of a contact
35 applications, the MT protocol can be implemented on top of the ST protocol
39 input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT
44 input_mt_slot(), with a slot as argument, at the beginning of each packet.
46 prepare for updates of the given slot.
[all …]
|
| /Documentation/arch/powerpc/ |
| D | associativity.rst | 5 Associativity represents the groupings of the various platform resources into
6 domains of substantially similar mean performance relative to resources outside
7 of that domain. Resources subsets of a given domain that exhibit better
9 are represented as being members of a sub-grouping domain. This performance
10 characteristic is presented in terms of NUMA node distance within the Linux kernel.
13 PAPR interface currently supports different ways of communicating these resource
17 Hypervisor indicates the type/form of associativity used via "ibm,architecture-vec-5 property".
18 Bit 0 of byte 5 in the "ibm,architecture-vec-5" property indicates usage of Form 0 or Form 1.
19 A value of 1 indicates the usage of Form 1 associativity. For Form 2 associativity
20 bit 2 of byte 5 in the "ibm,architecture-vec-5" property is used.
[all …]
|
| /Documentation/filesystems/ext4/ |
| D | group_descr.rst | 6 Each block group on the filesystem has one of these descriptors
9 standard configuration is for each block group to contain a full copy of
13 Notice how the group descriptor records the location of both bitmaps and
18 of the groups' bitmaps and inode tables into one long run in the first
19 group of the flex group.
36 checksum is the crc16 of the FS UUID, the group number, and the group
38 checksum is the lower 16 bits of the checksum of the FS UUID, the group
56 - Lower 32-bits of location of block bitmap.
60 - Lower 32-bits of location of inode bitmap.
64 - Lower 32-bits of location of inode table.
[all …]
|
| /Documentation/arch/riscv/ |
| D | hwprobe.rst | 18 The arguments are split into three groups: an array of key-value pairs, a CPU
26 value returned will be a logical AND of the values for the specified CPUs.
31 of sys_riscv_hwprobe(). Instead of populating the values of keys for a given
32 set of CPUs, the values of each key are given and the set of CPUs is reduced
33 by sys_riscv_hwprobe() to only those which match each of the key-value pairs.
36 means the result of a logical AND of the pair's value with the CPU's value is
39 CPU set returned is the reduction of all the online CPUs which can be
40 represented with a CPU set of size ``cpusetsize``.
48 * :c:macro:`RISCV_HWPROBE_KEY_MVENDORID`: Contains the value of ``mvendorid``,
51 * :c:macro:`RISCV_HWPROBE_KEY_MARCHID`: Contains the value of ``marchid``, as
[all …]
|
| /Documentation/admin-guide/device-mapper/ |
| D | vdo.rst | 10 corruption, relying instead on integrity protection of the storage below
17 Formatting a vdo volume requires the use of the 'vdoformat' tool, available
25 enter or come up in read-only mode. Because read-only mode is indicative of
26 data-loss, a positive action must be taken to bring vdo out of read-only
40 Each vdo volume reserves 3GB of space for metadata, or more depending on
43 requirements. An estimation of the space saved for a specific dataset can
68 The size of the device which the vdo volume will service,
69 in sectors. Must match the current logical size of the vdo
76 The size of the device holding the vdo volume, as a number
77 of 4096-byte blocks. Must match the current size of the vdo
[all …]
|
| D | statistics.rst | 5 Device Mapper supports the collection of I/O statistics on user-defined
6 regions of a DM device. If no regions are defined no statistics are
14 The I/O statistics counters for each step-sized area of a region are
19 histogram of latencies. All these counters may be accessed by sending
33 The creation of DM statistics will allocate memory via kmalloc or
34 fallback to using vmalloc space. At most, 1/4 of the overall system
50 a range of <length> 512-byte sectors
59 number of areas.
62 The number of optional arguments
69 instead of the "jiffies" variable. When this argument is
[all …]
|
| /Documentation/admin-guide/pm/ |
| D | intel_idle.rst | 16 ``intel_idle`` is a part of the
19 Nehalem and later generations of Intel processors, but the level of support for
27 logical CPU executing it is idle and so it may be possible to put some of the
29 arguments (passed in the ``EAX`` and ``ECX`` registers of the target CPU), the
30 first of which, referred to as a *hint*, can be used by the processor to
42 .. _intel-idle-enumeration-of-states:
44 Enumeration of Idle States
50 as C-states (in the ACPI terminology) or idle states. The list of meaningful
51 ``MWAIT`` hint values and idle states (i.e. low-power configurations of the
53 depend on the configuration of the platform.
[all …]
|
| /Documentation/devicetree/bindings/display/ |
| D | st,stih4xx.txt | 6 - reg: Physical base address of the IP registers and length of memory mapped region.
14 - reg: Physical base address of the IP registers and length of memory mapped region.
16 number of clocks may depend of the SoC type.
18 - clock-names: names of the clocks listed in clocks property in the same
22 This device must be the parent of all the sub-components and is responsible
23 of bind them.
26 - ranges: to allow probing of subdevices
29 must be a child of sti-display-subsystem
32 - reg: Physical base address of the IP registers and length of memory mapped region.
34 number of clocks may depend of the SoC type.
[all …]
|
| /Documentation/mm/ |
| D | zsmalloc.rst | 10 any object of size PAGE_SIZE/2 or larger would occupy an entire page.
11 This was one of the major issues with its predecessor (xvmalloc).
13 To overcome these issues, zsmalloc allocates a bunch of 0-order pages
19 For simplicity, zsmalloc can only allocate objects of size up to PAGE_SIZE
20 since this satisfies the requirements of all its current users (in the
27 location of the allocated object. The reason for this indirection is that
38 ``/sys/kernel/debug/zsmalloc/<user name>``. Here is a sample of stat output::
57 the number of zspages with usage ratio less than 10% (see below)
59 the number of zspages with usage ratio between 10% and 20%
61 the number of zspages with usage ratio between 20% and 30%
[all …]
|
| /Documentation/devicetree/bindings/riscv/ |
| D | extensions.yaml | 15 RISC-V has a large number of extensions, some of which are "standard"
22 made without the creation of a new extension.
24 ratified states, with the exception of the I, Zicntr & Zihpm extensions.
41 Due to revisions of the ISA specification, some deviations
43 Notably, riscv,isa was defined prior to the creation of the
57 version of the unprivileged ISA specification.
72 version of the unprivileged ISA specification.
75 the Zicntr and Zihpm extensions after the ratification of the
76 20191213 version of the unprivileged specification.
81 ratified in the 20191213 version of the unprivileged ISA
[all …]
|
| /Documentation/security/ |
| D | credentials.rst | 18 userspace programs. Linux has a variety of actionable objects, including:
28 As a part of the description of all these objects there is a set of
29 credentials. What's in the set depends on the type of object.
33 Amongst the credentials of most objects, there will be a subset that
34 indicates the ownership of that object. This is used for resource
42 Also amongst the credentials of those objects, there will be a subset that
43 indicates the 'objective context' of that object. This may or may not be
47 The objective context is used as part of the security calculation that is
54 Most of the objects in the system are inactive: they don't act on other
65 A subject has an additional interpretation of its credentials. A subset
[all …]
|
| /Documentation/arch/arm64/ |
| D | asymmetric-32bit.rst | 7 This document describes the impact of asymmetric 32-bit SoCs on the
8 execution of 32-bit (``AArch32``) applications.
16 of the CPUs are capable of executing 32-bit user applications. On such
19 ``execve(2)`` of 32-bit ELF binaries, with the latter returning
20 ``-ENOEXEC``. If the mismatch is detected during late onlining of a
24 Surprisingly, these SoCs have been produced with the intention of
26 well with the default behaviour of Linux.
29 altogether, so if you're stuck in the unenviable position of needing to
30 run 32-bit code on one of these transitionary platforms then you would
32 retirement. If neither of those options are practical, then read on.
[all …]
|