| /Documentation/admin-guide/cgroup-v1/ |
| D | devices.rst | 5 1. Description
8 Implement a cgroup to track and enforce open and mknod restrictions
9 on device files. A device cgroup associates a device access
10 whitelist with each cgroup. A whitelist entry has 4 fields.
11 'type' is a (all), c (char), or b (block). 'all' means it applies
13 either an integer or * for all. Access is a composition of r
16 The root device cgroup starts with rwm to 'all'. A child device
17 cgroup gets a copy of the parent. Administrators can then remove
18 devices from the whitelist or add new entries. A child cgroup can
19 never receive a device access which is denied by its parent.
[all …]
|
| /Documentation/w1/masters/ |
| D | w1-uart.rst | 13 UART 1-Wire bus driver. The driver utilizes the UART interface via the
14 Serial Device Bus to create the 1-Wire timing patterns as described in
15 the document `"Using a UART to Implement a 1-Wire Bus Master"`_.
17 .. _"Using a UART to Implement a 1-Wire Bus Master": https://www.analog.com/en/technical-articles/u…
20 open-drain mode. The timing patterns are generated by a specific
21 combination of baud-rate and transmitted byte, which corresponds to a
22 1-Wire read bit, write bit or reset pulse.
24 For instance the timing pattern for a 1-Wire reset and presence detect uses
27 for 1-Wire to 521 us. A present 1-Wire device changes the received byte by
29 the 1-Wire operation.
[all …]
|
| /Documentation/dev-tools/ |
| D | ktap.rst | 4 The Kernel Test Anything Protocol (KTAP), version 1
7 TAP, or the Test Anything Protocol is a format for specifying test results used
8 by a number of projects. It's website and specification are found at this `link
11 which don't align with the original TAP specification. Thus, a "Kernel TAP"
16 KTAP test results describe a series of tests (which may be nested: i.e., test
18 lines -- and a final result. The test structure and results are
30 there is a stagnant draft specification for TAP14, KTAP diverges from this in
31 a couple of places (notably the "Subtest" header), which are described where
37 All KTAP-formatted results begin with a "version line" which specifies which
41 - "KTAP version 1"
[all …]
|
| D | kcov.rst | 4 KCOV collects and exposes kernel code coverage information in a form suitable
5 for coverage-guided fuzzing. Coverage data of a running kernel is exported via
6 the ``kcov`` debugfs file. Coverage collection is enabled on a task basis, and
7 thus KCOV can capture precise coverage of a single system call.
10 to collect more or less stable coverage that is a function of syscall inputs.
46 The following program demonstrates how to use KCOV to collect coverage for a
47 single syscall from within a test program:
63 #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
69 #define KCOV_TRACE_CMP 1
76 /* A single fd descriptor allows coverage collection on a single
[all …]
|
| /Documentation/devicetree/bindings/usb/ |
| D | usb-device.yaml | 15 http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
22 A combined node shall be used instead of a device node and an interface node
23 for devices of class 0 or 9 (hub) with a single configuration and a single
26 A "hub node" is a combined node or an interface node that represents a USB
31 pattern: "^usb[0-9a-f]{1,4},[0-9a-f]{1,4}$"
37 but a device adhering to this binding may leave out all except
42 port to which this device is attached. The range is 1-255.
43 maxItems: 1
46 description: should be 1 for hub nodes with device nodes,
48 enum: [1, 2]
[all …]
|
| /Documentation/arch/x86/ |
| D | topology.rst | 26 The kernel does not care about the concept of physical sockets because a
28 the past a socket always contained a single package (see below), but with the
29 advent of Multi Chip Modules (MCM) a socket can hold more than one package. So
33 The topology of a system is described in the units of:
41 Packages contain a number of cores plus shared resources, e.g. DRAM
52 The number of threads in a package.
56 The number of cores in a package.
60 The maximum number of dies in a package.
72 packages within a socket. This value may differ from topo.die_id.
77 packages in a consistent way, we introduced the concept of logical package
[all …]
|
| /Documentation/admin-guide/device-mapper/ |
| D | switch.rst | 5 The device-mapper switch target creates a device that supports an
6 arbitrary mapping of fixed-size regions of I/O across a fixed set of
8 dynamically by sending the target a message.
10 It maps I/O to underlying block devices efficiently when there is a large
12 that would allow for a compact representation of the mapping such as
18 Dell EqualLogic and some other iSCSI storage arrays use a distributed
20 consists of a number of distinct storage arrays ("members") each having
21 independent controllers, disk storage and network adapters. When a LUN
24 The storage group exposes a single target discovery portal, no matter
26 session is connected to an eth port on a single member. Data to a LUN
[all …]
|
| D | dm-service-time.rst | 5 dm-service-time is a path selector module for device-mapper targets,
6 which selects a path with the shortest estimated service time for
10 of in-flight I/Os on a path with the performance value of the path.
11 The performance value is a relative throughput value among all paths
12 in a path-group, and it can be specified as a table argument.
28 If not given, minimum value '1' is used.
30 other paths having a positive value are available.
36 'A' if the path is active, 'F' if the path is failed.
51 Basically, dm-service-time selects a path having minimum service time
59 1. If the paths have the same 'relative_throughput', skip
[all …]
|
| /Documentation/devicetree/bindings/misc/ |
| D | xlnx,sd-fec.yaml | 14 The Soft Decision Forward Error Correction (SDFEC) Engine is a Hard IP block
16 The LDPC decode & encode functionality is capable of covering a range of
26 maxItems: 1
62 maxItems: 1
69 a codeword-by-codeword basis. The Turbo code decoding is required by LTE
77 Configures the DIN AXI stream where a value of 1
78 configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a width
81 enum: [ 1, 2, 4 ]
85 A value 0 indicates that the DIN_WORDS interface is
86 driven with a fixed value and is not present on the device, a value of 1
[all …]
|
| /Documentation/devicetree/bindings/net/ |
| D | renesas,ether.yaml | 20 - renesas,gether-r8a7740 # device is a part of R8A7740 SoC
21 - renesas,gether-r8a77980 # device is a part of R8A77980 SoC
22 - renesas,ether-r7s72100 # device is a part of R7S72100 SoC
23 - renesas,ether-r7s9210 # device is a part of R7S9210 SoC
26 - renesas,ether-r8a7778 # device is a part of R8A7778 SoC
27 - renesas,ether-r8a7779 # device is a part of R8A7779 SoC
29 - renesas,rcar-gen1-ether # a generic R-Car Gen1 device
32 - renesas,ether-r8a7742 # device is a part of R8A7742 SoC
33 - renesas,ether-r8a7743 # device is a part of R8A7743 SoC
34 - renesas,ether-r8a7745 # device is a part of R8A7745 SoC
[all …]
|
| /Documentation/devicetree/bindings/infiniband/ |
| D | hisilicon-hns-roce.txt | 3 Hisilicon RoCE engine is a part of network subsystem.
13 - eth-handle: phandle, specifies a reference to a node
14 representing a ethernet device.
15 - dsaf-handle: phandle, specifies a reference to a node
16 representing a dsaf device.
17 - node_guid: a number that uniquely identifies a device or component
22 - interrupts: should contain 32 completion event irq,1 async event irq
23 and 1 event overflow irq.
26 - hns-roce-async: 1 async event irq
35 node-guid = [00 9A CD 00 00 01 02 03];
[all …]
|
| /Documentation/input/ |
| D | input.rst | 12 Input subsystem is a collection of drivers that is designed to support
14 drivers/input, although quite a few live in drivers/hid and
18 loaded before any other of the input modules - it serves as a way of
32 a simulated PS/2 interface to GPM and X, and so on.
49 will be available as a character device on major 13, minor 63::
51 crw-r--r-- 1 root root 13, 63 Mar 28 22:45 mice
99 crw-r--r-- 1 root root 13, 64 Apr 1 10:49 event0
100 crw-r--r-- 1 root root 13, 65 Apr 1 10:50 event1
101 crw-r--r-- 1 root root 13, 66 Apr 1 10:50 event2
102 crw-r--r-- 1 root root 13, 67 Apr 1 10:50 event3
[all …]
|
| /Documentation/misc-devices/ |
| D | oxsemi-tornado.rst | 8 by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock.
12 value from 1 to 63.875 in increments of 0.125, and then the usual 16-bit
13 divisor is used as with the original 8250, to divide the frequency by a
14 value from 1 to 65535. Finally a programmable oversampling rate is used
31 the prescaler or otherwise it is bypassed as if the value of 1 was used.
37 By using these parameters rates from 15625000bps down to 1bps can be
43 the requested rate (r), the actual rate yielded (a) and its deviation
50 r: 15625000, a: 15625000.00, d: 0.0000%, tcr: 4, cpr: 1.000, div: 1
51 r: 12500000, a: 12500000.00, d: 0.0000%, tcr: 5, cpr: 1.000, div: 1
52 r: 10416666, a: 10416666.67, d: 0.0000%, tcr: 6, cpr: 1.000, div: 1
[all …]
|
| /Documentation/userspace-api/media/v4l/ |
| D | pixfmt-rgb.rst | 9 These formats encode each pixel as a triplet of RGB values. They are packed
12 bits required to store a pixel is not aligned to a byte boundary, the data is
20 or a permutation thereof, collectively referred to as alpha formats) depend on
24 a meaningful value. Otherwise, when the device doesn't capture an alpha channel
25 but can set the alpha bit to a user-configurable value, the
28 the value specified by that control. Otherwise a corresponding format without
34 filled with meaningful values by applications. Otherwise a corresponding format
38 Formats that contain padding bits are named XRGB (or a permutation thereof).
44 - In all the tables that follow, bit 7 is the most significant bit in a byte.
46 respectively. 'a' denotes bits of the alpha component (if supported by the
[all …]
|
| /Documentation/devicetree/bindings/display/ |
| D | mipi-dsi-bus.txt | 4 The MIPI Display Serial Interface specifies a serial bus and a protocol for
5 communication between a host and up to four peripherals. This document will
6 define the syntax used to represent a DSI bus in a device tree.
11 Each DSI host provides a DSI bus. The DSI host controller's node contains a
15 The following assumes that only a single peripheral is connected to a DSI
22 a DSI host, the following properties apply to a node representing a DSI host.
26 bus. DSI peripherals are addressed using a 2-bit virtual channel number, so
27 a maximum of 4 devices can be addressed on a single bus. Hence the value of
28 this property should be 1.
29 - #size-cells: Should be 0. There are cases where it makes sense to use a
[all …]
|
| /Documentation/staging/ |
| D | lzo.rst | 8 This is not a specification. No specification seems to be publicly available
20 The stream is composed of a series of instructions, operands, and data. The
21 instructions consist in a few bits representing an opcode, and bits forming
26 - a distance when copying data from the dictionary (past output buffer)
27 - a length (number of bytes to copy from dictionary)
29 as a piece of information for next instructions.
32 extra data can be a complement for the operand (eg: a length or a distance
33 encoded on larger values), or a literal to be copied to the output buffer.
35 The first byte of the block follows a different encoding from other bytes, it
39 Lengths are always encoded on a variable size starting with a small number
[all …]
|
| /Documentation/hid/ |
| D | hid-sensor.rst | 5 which are connected to a sensor hub. The sensor hub is a HID device and it provides
6 a report descriptor conforming to HID 1.12 sensor usage tables.
10 hardware vendors to provide a consistent Plug And Play interface at the USB boundary,
18 example a part of report descriptor can look like::
20 INPUT(1)[INPUT]
24 Usage(1)
29 Report Count(1)
37 (0x045f) with a logical minimum value of -32767 and logical maximum of 32767. The
46 data fields. It is difficult to have a common input event to user space applications,
56 The core driver (hid-sensor-hub) registers as a HID driver. It parses
[all …]
|
| /Documentation/devicetree/bindings/sound/ |
| D | ti,tlv320adcx140.yaml | 17 family supports line and microphone Inputs, and offers a programmable
33 maxItems: 1
38 maxItems: 1
51 1 - Mic bias is set to VREF × 1.096
54 enum: [0, 1, 6]
60 1 - Set VREF to 2.5V
63 enum: [0, 1, 2]
72 1 - Odd channel is latched on the positive edge and even channel is
75 PDMIN1 - PDMCLK latching edge used for channel 1 and 2 data
81 minItems: 1
[all …]
|
| /Documentation/networking/ |
| D | snmp_counter.rst | 33 ICMP and so on. If no one listens on a raw socket, only kernel
64 for the same packet, you might find that IpInReceives count 1, but
78 scenarios: (1) The IP address is invalid. (2) The destination IP
79 address is not a local address and IP forwarding is not enabled
85 This counter means the packet is dropped when the IP stack receives a
86 packet and can't find a route for it from the route table. It might
88 not a local address and there is no route for the destination IP
138 ICMP output path will check the header of a raw socket, so the
140 a userspace program.
194 straightforward. The 'In' counter means kernel receives such a packet
[all …]
|
| /Documentation/devicetree/bindings/pci/ |
| D | pci-iommu.txt | 4 Each PCI(e) device under a root complex is uniquely identified by its Requester
5 ID (AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
8 For the purpose of this document, when treated as a numeric value, a RID is
17 Requester ID. While a given PCI device can only master through one IOMMU, a
18 root complex may split masters across a set of IOMMUs (e.g. with one IOMMU per
22 and a mechanism is required to map from a PCI device to its IOMMU and sideband
35 - iommu-map: Maps a Requester ID to an IOMMU and associated IOMMU specifier
44 - iommu-map-mask: A mask to be applied to each Requester ID prior to being
48 Example (1)
52 #address-cells = <1>;
[all …]
|
| /Documentation/filesystems/ext4/ |
| D | blockgroup.rst | 6 The layout of a standard block group is approximately as follows (each
7 of these fields is discussed in a separate section below):
10 :widths: 1 1 1 1 1 1 1 1
11 :header-rows: 1
22 - 1 block
25 - 1 block
26 - 1 block
34 1024, then block 0 is marked in use and the superblock goes in block 1.
41 not all block groups necessarily host a redundant copy (see following
42 paragraph for more details). If the group does not have a redundant
[all …]
|
| /Documentation/scheduler/ |
| D | sched-bwc.rst | 9 CFS bandwidth control is a CONFIG_FAIR_GROUP_SCHED extension which allows the
10 specification of the maximum CPU bandwidth available to a group or hierarchy.
12 The bandwidth allowed for a group is specified using a quota and period. Within
13 each given "period" (microseconds), a task group is allocated up to "quota"
20 A group's unassigned quota is globally tracked, being refreshed back to
22 is transferred to cpu-local "silos" on a demand basis. The amount transferred
32 (U = \Sum u_i) <= 1
35 stable. After all, if U were > 1, then for every second of walltime,
36 we'd have to run more than a second of program time, and obviously miss
40 The burst feature observes that a workload doesn't always executes the full
[all …]
|
| /Documentation/hwmon/ |
| D | acpi_power_meter.rst | 20 the ACPI 4.0 spec (Chapter 10.4). These devices have a simple set of
21 features--a power meter that returns average power use over a configurable
22 interval, an optional capping mechanism, and a couple of trip points. The
29 The `power[1-*]_is_battery` knob indicates if the power supply is a battery.
30 Both `power[1-*]_average_{min,max}` must be set before the trip points will work.
32 socket and a poll notification will be sent to the appropriate
33 `power[1-*]_average` sysfs file.
35 The `power[1-*]_{model_number, serial_number, oem_info}` fields display
39 Some computers have the ability to enforce a power cap in hardware. If this is
40 the case, the `power[1-*]_cap` and related sysfs files will appear. When the
[all …]
|
| /Documentation/ |
| D | memory-barriers.txt | 14 This document is not a specification; it is intentionally (for the sake of
16 meant as a guide to using the various memory barriers provided by Linux, but
23 To repeat, this document is not a specification of what Linux expects from
28 (1) to specify the minimum functionality that one can rely on for any
31 (2) to provide a guide as to how to use the barriers that are available.
37 Note also that it is possible that a barrier may be a no-op for an
118 | CPU 1 |<----->| Memory |<----->| CPU 2 |
135 Each CPU executes a program that generates memory access operations. In the
136 abstract CPU, memory operation ordering is very relaxed, and a CPU may actually
142 So in the above diagram, the effects of the memory operations performed by a
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-platform-chipidea-usb-otg | 6 Set a_bus_req(A-device bus request) input to be 1 if
7 the application running on the A-device wants to use the bus,
10 be set to 1 by kernel in response to remote wakeup signaling
11 from the B-device, the A-device should decide to resume the bus.
13 Valid values are "1" and "0".
15 Reading: returns 1 if the application running on the A-device
23 The a_bus_drop(A-device bus drop) input is 1 when the
24 application running on the A-device wants to power down
25 the bus, and is 0 otherwise, When a_bus_drop is 1, then
28 Valid values are "1" and "0".
[all …]
|