Searched full:data (Results 1 – 25 of 2277) sorted by relevance
12345678910>>...92
| /Documentation/driver-api/md/ |
| D | raid5-cache.rst | 5 Raid 4/5/6 could include an extra disk for data cache besides normal RAID
7 caches data to the RAID disks. The cache can be in write-through (supported
26 shutdown can cause data in some stripes to not be in consistent state, eg, data
29 unclean shutdown. We call an array degraded if it has inconsistent data. MD
31 resync completes, any system crash will expose the chance of real data
34 The write-through cache will cache all data on cache disk first. After the data
35 is safe on the cache disk, the data will be flushed onto RAID disks. The
36 two-step write will guarantee MD can recover correct data after unclean
40 filesystems) after the data is safe on RAID disks, so cache disk failure
41 doesn't cause data loss. Of course cache disk failure means the array is
[all …]
|
| D | raid5-ppl.rst | 7 may become inconsistent with data on other member disks. If the array is also
9 disks is missing. This can lead to silent data corruption when rebuilding the
10 array or using it is as degraded - data calculated from parity for array blocks
15 Partial parity for a write operation is the XOR of stripe data chunks not
16 modified by this write. It is just enough data needed for recovering from the
19 which chunk writes have completed. If one of the not modified data disks of
26 When handling a write request PPL writes partial parity before new data and
35 not a true journal. It does not protect from losing in-flight data, only from
36 silent data corruption. If a dirty disk of a stripe is lost, no PPL recovery is
38 arbitrary data in the written part of a stripe if that disk is lost. In such
[all …]
|
| /Documentation/filesystems/ext4/ |
| D | inlinedata.rst | 3 Inline Data
6 The inline data feature was designed to handle the case that a file's
7 data is so tiny that it readily fits inside the inode, which
9 file is smaller than 60 bytes, then the data are stored inline in
12 “system.data” within the inode body (“ibody EA”). This of course
14 If the data size increases beyond i_block + ibody EA, a regular block
18 inline data, one ought to be able to store 160 bytes of data in a
22 The inline data feature requires the presence of an extended attribute
23 for “system.data”, even if the attribute value is zero length.
30 entries; see ``struct ext4_dir_entry``. If there is a “system.data”
[all …]
|
| /Documentation/devicetree/bindings/media/ |
| D | video-interfaces.yaml | 14 Video data pipelines usually consist of external devices, e.g. camera sensors,
16 video DMA engines and video data processors.
22 Data interfaces on all video devices are described by their child 'port' nodes.
23 Configuration of a port depends on other devices participating in the data
54 configuration of this device for data exchange with other device. In most
60 where supported by a device. For example, in case where a data interface of
61 a device is partitioned into multiple data busses, e.g. 16-bit input port
63 and data-shift properties can be used to assign physical data lines to each
83 vertical synchronization signals are provided to the slave device (data
84 source) by the master device (data sink). In the master mode the data
[all …]
|
| /Documentation/devicetree/bindings/sound/ |
| D | adi,max98396.yaml | 14 The device provides a PCM interface for audio data and a standard
15 I2C interface for control data communication.
65 Selects the PCM data input channel that is routed to the speaker
74 For cases where a single combined channel for the I/V sense data
76 a single data output channel on alternating frames.
77 In this configuration, the current and voltage data will be frame
83 Enables the "data monitor stuck" feature. Once the data monitor is
84 enabled, it actively monitors the selected input data (from DIN) to the
85 speaker amplifier. Once a data error is detected, the data monitor
91 Sets the threshold for the "data monitor stuck" feature, in bits.
[all …]
|
| D | rt5659.txt | 23 - realtek,dmic1-data-pin
25 1: using IN2N pin as dmic1 data pin
26 2: using GPIO5 pin as dmic1 data pin
27 3: using GPIO9 pin as dmic1 data pin
28 4: using GPIO11 pin as dmic1 data pin
30 - realtek,dmic2-data-pin
32 1: using IN2P pin as dmic2 data pin
33 2: using GPIO6 pin as dmic2 data pin
34 3: using GPIO10 pin as dmic2 data pin
35 4: using GPIO12 pin as dmic2 data pin
|
| /Documentation/crypto/ |
| D | userspace-if.rst | 80 system calls to send data to the kernel or obtain data from the
91 copying of the output data to its final destination can be avoided.
103 filled struct sockaddr data structure. This data structure must be
120 Using the send() system call, the application provides the data that
142 initialization, the struct sockaddr data structure must be filled as
154 Before data can be sent to the kernel using the write/send system call
158 Using the sendmsg() system call, the application provides the data that
160 specified with the data structure provided by the sendmsg() system call.
163 struct cmsghdr data structure. See recv(2) and cmsg(3) for more
164 information on how the cmsghdr data structure is used together with the
[all …]
|
| /Documentation/admin-guide/device-mapper/ |
| D | dm-integrity.rst | 13 writes sector data and integrity tags into a journal, commits the journal
14 and then copies the data and integrity tags to their respective location.
17 situation the dm-crypt target creates the integrity data and passes them
21 error is returned instead of random data.
25 mode, the dm-integrity target can be used to detect silent data
30 region's data and integrity tags are not synchronized - if the machine
32 is faster than the journal mode, because we don't have to write the data
33 twice, but it is also less reliable, because if data corruption happens
48 a full write to the data covered by a single buffer.
77 not used and data sectors and integrity tags are written
[all …]
|
| D | persistent-data.rst | 2 Persistent data
10 different targets were rolling their own data structures, for example:
17 Maintaining these data structures takes a lot of work, so if possible
20 The persistent-data library is an attempt to provide a re-usable
29 under drivers/md/persistent-data.
36 This provides access to the data on disk in fixed sized-blocks. There
38 keep data that is being used in the cache.
40 Clients of persistent-data are unlikely to use this directly.
52 ensures that all data is flushed before it writes the superblock.
62 On-disk data structures that keep track of reference counts of blocks.
[all …]
|
| /Documentation/i2c/ |
| D | i2c-protocol.rst | 18 Data (8 bits) A plain data byte.
20 [..] Data sent by I2C device, as opposed to data sent by the
30 S Addr Wr [A] Data [A] Data [A] ... [A] Data [A] P
38 S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
50 S Addr Rd [A] [Data] NA S Addr Wr [A] Data [A] P
74 S Addr Rd [A] [Data] NA Data [A] P
81 This is often used to gather transmits from multiple data buffers in
91 S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P
|
| D | smbus-protocol.rst | 24 single data byte, the functions using SMBus protocol operation names execute
46 Comm (8 bits) Command byte, a data byte which often selects a register on
48 Data (8 bits) A plain data byte. DataLow and DataHigh represent the low and
50 Count (8 bits) A data byte containing the length of a block operation.
52 [..] Data sent by I2C device, as opposed to data sent by the host
77 S Addr Rd [A] [Data] NA P
92 S Addr Wr [A] Data [A] P
105 S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Data] NA P
115 This operation is very like Read Byte; again, data is read from a
117 byte. But this time, the data is a complete word (16 bits)::
[all …]
|
| /Documentation/translations/zh_CN/core-api/ |
| D | kref.rst | 53 struct my_data *data;
55 data = kmalloc(sizeof(*data), GFP_KERNEL);
56 if (!data)
58 kref_init(&data->refcount);
70 kref_get(&data->refcount);
77 kref_put(&data->refcount, data_release);
91 struct my_data *data = container_of(ref, struct my_data, refcount);
92 kfree(data);
97 struct my_data *data = cb_data;
99 . do stuff with data here
[all …]
|
| /Documentation/trace/coresight/ |
| D | coresight-perf.rst | 10 Perf is able to locally access CoreSight trace data and store it to the
11 output perf data files. This data can then be later decoded to give the
13 can log such data with a perf record command like::
18 a perf.data trace file. That file would have AUX sections if CoreSight
22 perf report --stdio --dump -i perf.data
24 You should find some sections of this file have AUX data blocks like::
28 . ... CoreSight ETM Trace data: size 73168 bytes
40 If you see these above, then your system is tracing CoreSight data
89 Check Arm CoreSight trace data recording and synthesized samples
90 Check Arm SPE trace data recording and synthesized samples
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-kernel-boot_params | 5 files: "data" and "version" and one subdirectory "setup_data".
12 "data" file is the binary representation of struct boot_params.
17 "setup_data" subdirectory contains the setup_data data
22 files "type" and "data". "type" file is the string
23 representation of setup_data type. "data" file is the binary
29 |__ data
32 | | |__ data
35 | |__ data
|
| /Documentation/admin-guide/hw-vuln/ |
| D | processor_mmio_stale_data.rst | 2 Processor MMIO Stale Data Vulnerabilities
5 Processor MMIO Stale Data Vulnerabilities are a class of memory-mapped I/O
6 (MMIO) vulnerabilities that can expose data. The sequences of operations for
7 exposing data range from simple to very complex. Because most of the
12 stale data into core fill buffers where the data can subsequently be inferred
16 are similar to those used to mitigate Microarchitectural Data Sampling (MDS) or
17 those used to mitigate Special Register Buffer Data Sampling (SRBDS).
19 Data Propagators
21 Propagators are operations that result in stale data being copied or moved from
22 one microarchitectural buffer or register to another. Processor MMIO Stale Data
[all …]
|
| /Documentation/admin-guide/ |
| D | edid.rst | 16 - The graphics board is unable to detect any EDID data.
17 - The graphics board incorrectly forwards EDID data to the driver.
18 - The monitor sends no or bogus EDID data.
19 - A KVM sends its own EDID data instead of querying the connected monitor.
26 individually prepared or corrected EDID data set in the /lib/firmware
28 (see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
31 not contain code to create these data. In order to elucidate the origin
33 individual data for a specific misbehaving monitor, commented sources
36 To create binary EDID and C source code files from the existing data
40 replace the settings with your own data and add a new target to the
[all …]
|
| /Documentation/devicetree/bindings/net/ |
| D | micrel-ksz90x1.txt | 52 - rxd0-skew-ps : Skew control of RX data 0 pad
53 - rxd1-skew-ps : Skew control of RX data 1 pad
54 - rxd2-skew-ps : Skew control of RX data 2 pad
55 - rxd3-skew-ps : Skew control of RX data 3 pad
56 - txd0-skew-ps : Skew control of TX data 0 pad
57 - txd1-skew-ps : Skew control of TX data 1 pad
58 - txd2-skew-ps : Skew control of TX data 2 pad
59 - txd3-skew-ps : Skew control of TX data 3 pad
112 data pads, and the rxdv-skew-ps, txen-skew-ps control pads.
144 - rxd0-skew-ps : Skew control of RX data 0 pad
[all …]
|
| /Documentation/litmus-tests/locking/ |
| D | DCL-broken.litmus | 12 int data;
15 P0(int *flag, int *data, spinlock_t *lck)
26 WRITE_ONCE(*data, 1);
31 r2 = READ_ONCE(*data);
34 P1(int *flag, int *data, spinlock_t *lck)
45 WRITE_ONCE(*data, 1);
50 r2 = READ_ONCE(*data);
53 locations [flag;data;0:r0;0:r1;1:r0;1:r1]
|
| D | DCL-fixed.litmus | 13 int data;
16 P0(int *flag, int *data, spinlock_t *lck)
27 WRITE_ONCE(*data, 1);
32 r2 = READ_ONCE(*data);
35 P1(int *flag, int *data, spinlock_t *lck)
46 WRITE_ONCE(*data, 1);
51 r2 = READ_ONCE(*data);
54 locations [flag;data;0:r0;0:r1;1:r0;1:r1]
|
| /Documentation/networking/device_drivers/cellular/qualcomm/ |
| D | rmnet.rst | 18 handle multiple private data networks (PDN) like a default internet, tethering,
23 Aggregation is required to achieve high data rates. This involves hardware
30 a. MAP packet v1 (data / control)
37 Function Command / Data Reserved Pad Multiplexer ID Payload length
42 Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command
43 or data packet. Command packet is used for transport level flow control. Data
51 Multiplexer ID is to indicate the PDN on which data has to be sent.
56 b. Map packet v4 (data / control)
63 Function Command / Data Reserved Pad Multiplexer ID Payload length
68 Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command
[all …]
|
| /Documentation/networking/ |
| D | tls.rst | 11 TCP. TLS provides end-to-end data integrity and confidentiality.
29 data-path to the kernel. There is a separate socket option for moving
64 Sending TLS application data
67 After setting the TLS_TX socket option all application data sent over this
76 send() data is directly encrypted from the userspace buffer provided
79 The sendfile system call will send the file's data over TLS records of maximum
92 The kernel will need to allocate a buffer for the encrypted data.
96 -ENOMEM and some data was left on the socket buffer from a previous
97 call using MSG_MORE, the MSG_MORE data is left on the socket buffer.
99 Receiving TLS application data
[all …]
|
| /Documentation/devicetree/bindings/display/ |
| D | lvds.yaml | 15 incompatible data link layers have been used over time to transmit image data
30 data-mapping:
38 LVDS data mappings are defined as follows.
40 - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
41 [VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
51 - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
52 specifications. Data are transferred as follows on 4 LVDS lanes.
63 - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
64 Data are transferred as follows on 4 LVDS lanes.
79 CTL2: Data Enable
[all …]
|
| /Documentation/userspace-api/media/v4l/ |
| D | dev-rds.rst | 10 The Radio Data System transmits supplementary information in binary
41 driver only passes RDS blocks without interpreting the data the
43 :ref:`Reading RDS data <reading-rds-data>`. For future use the flag
52 ``V4L2_TUNER_SUB_RDS`` will be set if RDS data was detected.
64 blocks without interpreting the data the ``V4L2_TUNER_CAP_RDS_BLOCK_IO``
68 :ref:`Writing RDS data <writing-rds-data>` and
71 .. _reading-rds-data:
73 Reading RDS data
76 RDS data can be read from the radio device with the
77 :c:func:`read()` function. The data is packed in groups of
[all …]
|
| /Documentation/core-api/ |
| D | kref.rst | 22 To use a kref, add one to your data structures like::
33 The kref can occur anywhere within the data structure.
41 struct my_data *data;
43 data = kmalloc(sizeof(*data), GFP_KERNEL);
44 if (!data)
46 kref_init(&data->refcount);
60 kref_get(&data->refcount);
67 kref_put(&data->refcount, data_release);
80 For example, if you allocate some data and then pass it to another
85 struct my_data *data = container_of(ref, struct my_data, refcount);
[all …]
|
| /Documentation/userspace-api/ |
| D | iommu.rst | 41 Although the data structures defined in IOMMU UAPI are self-contained,
47 When IOMMU UAPI gets extended, the data structures can *only* be
56 method. The IOMMU driver processes the data based on flags which
64 Though at the same time, argsz is user provided data which is not
65 trusted. The argsz field allows the user app to indicate how much data
80 range. The data may contain garbage.
114 Data Passing Example with VFIO
122 IOMMU UAPI data is the host IOMMU driver. VFIO facilitates user-kernel
126 VFIO layer conveys the data structures down to the IOMMU driver. It
132 __u8 data[];
[all …]
|
12345678910>>...92