/linux-6.6.21/Documentation/networking/devlink/ |
D | nfp.rst | 46 - stored, running 49 - stored, running 52 - stored, running 55 - stored, running 58 - stored, running 61 - stored, running 64 - stored, running
|
D | bnxt.rst | 66 - stored, running 69 - stored, running 72 - stored, running 78 - stored, running 81 - stored, running
|
D | devlink-info.rst | 73 * - ``stored`` 78 ``stored`` versions when new software is flashed, it must not report 82 components stored on the flash should feature in both the ``running`` and 83 ``stored`` sections, if device is capable of reporting ``stored`` versions 119 ``bundle_id`` can appear in both ``running`` and ``stored`` versions,
|
D | devlink-flash.rst | 61 On-disk firmware files are usually stored in ``/lib/firmware/``. 71 (``fixed``, ``running``, ``stored``). 79 ``running`` and ``stored`` firmware versions identify the firmware running 95 if $want_flash_vers != devlink-dev-info['stored']:
|
/linux-6.6.21/Documentation/ABI/testing/ |
D | sysfs-class-switchtec | 18 Description: Component identifier as stored in the hardware (eg. PM8543) 27 Description: Component revision stored in the hardware (read only) 35 Description: Component vendor as stored in the hardware (eg. MICROSEM) 44 Description: Device version as stored in the hardware (read only) 76 Description: Product identifier as stored in the hardware (eg. PSX 48XG3) 85 Description: Product revision stored in the hardware (eg. RevB) 94 Description: Product vendor as stored in the hardware (eg. MICROSEM)
|
D | sysfs-class-rc-nuvoton | 6 Reading this file returns the stored CIR wakeup sequence. 12 Note: Some systems reset the stored wakeup sequence to a
|
D | sysfs-driver-intel-m10-bmc | 23 that is managed by the Intel MAX10 BMC. It is stored in 34 MAX10 BMC. This value is stored in FLASH and is mirrored
|
D | sysfs-bus-iio-isl29501 | 37 stored in in_proximity0_calib_phase_temp_a and 47 The value stored in sensor is displayed when read from.
|
/linux-6.6.21/Documentation/filesystems/ext4/ |
D | attributes.rst | 6 Extended attributes (xattrs) are typically stored in a separate data 23 attribute's value to be stored in a separate data block, though as of 29 Extended attributes, when stored after the inode, have a header 89 long. When stored in an external block, the ``struct ext4_xattr_entry`` 90 entries must be stored in sorted order. The sort order is 92 Attributes stored inside an inode do not need be stored in sorted order. 113 - Location of this attribute's value on the disk block where it is stored. 120 - The inode where the value is stored. Zero indicates the value is in the 141 are stored starting at the end of the block and grow towards the 188 POSIX ACLs are stored in a reduced version of the Linux kernel (and [all …]
|
D | checksums.rst | 11 lower 16 bits are stored. Enabling the 64bit feature increases the data 12 structure size so that full 32-bit checksums can be stored for many data 62 - UUID + the entire bitmap. Checksums are stored in the group descriptor, 72 descriptor). In all cases, only the lower 16 bits are stored.
|
D | verity.rst | 12 stored after the end of the file data itself, in the following format: 19 <fsverity_merkle_tree>`, with the tree levels stored in order from 20 root to leaf, and the tree blocks within each level stored in their
|
/linux-6.6.21/Documentation/networking/device_drivers/ethernet/amd/ |
D | pds_core.rst | 41 stored: 61 - stored 62 - Version of firmware stored in the goldfw slot 64 - stored 65 - Version of firmware stored in the mainfwa slot 67 - stored 68 - Version of firmware stored in the mainfwb slot
|
/linux-6.6.21/drivers/char/mwave/ |
D | README | 18 If the dsp irq has not been setup and stored in bios by the 23 If the dsp io range has not been setup and stored in bios by the 28 If the mwave's uart irq has not been setup and stored in bios by the 33 If the uart io range has not been setup and stored in bios by the
|
/linux-6.6.21/Documentation/filesystems/ |
D | squashfs.rst | 110 these are stored here. 133 information has to be stored. 138 Like inodes, directories are packed into compressed metadata blocks, stored 170 of each datablock is stored in a block list contained within the 189 fragment lookup table is itself stored compressed into metadata blocks. 199 stored compressed into metadata blocks. A second index table is used to 213 This table is stored compressed into metadata blocks. A second index table is 221 for each inode are stored in a list, each list entry containing a type, 225 is stored inline (in which case the value field contains the xattr value), 226 or if it is stored out of line (in which case the value field stores a [all …]
|
D | qnx6.rst | 55 Each of these root nodes holds information like total size of the stored 68 Data leaves are always on the lowest level. So no data is stored on upper 100 The filesize is stored 64bit. Inode counting starts with 1. (while long 119 record plus the longfile inode number also stored in that record. 143 Long filenames are stored in a separate addressing tree. The staring point 151 is a limit of 510 bytes for the actual filename stored. 156 The qnx6fs filesystem allocation bitmap is stored in a tree under bitmap
|
/linux-6.6.21/fs/nls/ |
D | Kconfig | 44 native language character sets. These character sets are stored 56 native language character sets. These character sets are stored 68 native language character sets. These character sets are stored 81 native language character sets. These character sets are stored in 97 native language character sets. These character sets are stored in 112 native language character sets. These character sets are stored in 123 native language character sets. These character sets are stored in 134 native language character sets. These character sets are stored in 145 native language character sets. These character sets are stored in 156 native language character sets. These character sets are stored in [all …]
|
/linux-6.6.21/Documentation/fb/ |
D | api.rst | 46 Pixels are stored in memory in hardware-dependent formats. Applications need 51 additional information, which are stored in the variable screen information 55 macropixels. Types describe how macropixels are stored in memory. The following 60 Macropixels are stored contiguously in a single plane. If the number of bits 83 belonging to different planes, is stored in the fixed screen information 88 Macropixels are stored in memory as described by the format FOURCC identifier 89 stored in the variable screen information grayscale field. 93 Pixels are black or white and stored on a number of bits (typically one) 104 Pixels are black or white and stored on a number of bits (typically one) 119 Each component is stored in a macropixel according to the variable screen [all …]
|
/linux-6.6.21/Documentation/userspace-api/media/v4l/ |
D | pixfmt-inzi.rst | 22 The first plane - Infrared data - is stored according to 24 Each pixel is 16-bit cell, with actual data stored in the 10 LSBs 34 Each cell is a 16-bit word with more significant data stored at higher
|
D | pixfmt-srggb16.rst | 23 sample. Each sample is stored in a 16-bit word. Each n-pixel row contains 25 rows. Bytes are stored in memory in little endian order. They are
|
D | pixfmt-intro.rst | 16 data can still be stored and retrieved in the proprietary format. For 44 For some formats, data is stored in separate, discontiguous memory 47 :ref:`YUV422 <V4L2-PIX-FMT-YUV422M>` frame is normally stored in one
|
/linux-6.6.21/arch/arm/nwfpe/ |
D | softfloat-macros | 39 The result is stored in the location pointed to by `zPtr'. 64 The result is stored in the location pointed to by `zPtr'. 89 64 nonzero bits; this is stored at the location pointed to by `z0Ptr'. The 93 bits shifted off were all zero. This extra result is stored in the location 138 which are stored at the locations pointed to by `z0Ptr' and `z1Ptr'. 173 nonzero. The result is broken into two 64-bit pieces which are stored at 214 stored at the locations pointed to by `z0Ptr' and `z1Ptr'. The bits shifted 218 were all zero. This extra result is stored in the location pointed to by 285 pieces which are stored at the locations pointed to by `z0Ptr' and `z1Ptr'. 304 64-bit pieces which are stored at the locations pointed to by `z0Ptr', [all …]
|
/linux-6.6.21/Documentation/devicetree/bindings/nvmem/ |
D | nvmem.yaml | 14 configuration data stored in NVMEMs like eeprom, efuses and so on. 16 On a significant proportion of boards, the manufacturer has stored 19 where to retrieve these data from, and where they are stored on the
|
/linux-6.6.21/Documentation/gpu/amdgpu/ |
D | flashing.rst | 25 * Writing the name of a firmware payload stored in `/lib/firmware/amdgpu` to the sysfs file will in… 27 The firmware payload stored in `/lib/firmware/amdgpu` can be named any name
|
/linux-6.6.21/Documentation/bpf/ |
D | map_sk_storage.rst | 14 storage. The values for maps of type ``BPF_MAP_TYPE_SK_STORAGE`` are stored 72 identified by a `socket` ``fd`` stored in the pointer ``key``. The pointer 96 the socket identified by a `socket` ``fd`` stored in the pointer 108 socket identified by a `socket` ``fd`` stored in the pointer ``key``. Returns
|
/linux-6.6.21/drivers/infiniband/hw/mlx5/ |
D | mr.c | 153 (ent->reserved - ent->stored) > MAX_PENDING_REG_MR) in push_mkey_locked() 165 if (to_store && ent->stored == ent->reserved) in push_mkey_locked() 172 if (ent->stored != ent->reserved) in push_mkey_locked() 174 ent->stored, in push_mkey_locked() 177 ent->stored++; in push_mkey_locked() 226 old = __xa_store(&ent->mkeys, ent->stored, xa_mk_value(mkey), 0); in push_to_reserved() 228 ent->stored++; in push_to_reserved() 235 ent->stored--; in pop_stored_mkey() 238 if (ent->stored == ent->reserved) { in pop_stored_mkey() 239 xa_mkey = __xa_erase(&ent->mkeys, ent->stored); in pop_stored_mkey() [all …]
|