include/uapi/mtd/mtd-abi.h
Source file repositories/reference/linux-study-clean/include/uapi/mtd/mtd-abi.h
File Facts
- System
- Linux kernel
- Corpus path
include/uapi/mtd/mtd-abi.h- Extension
.h- Size
- 11879 bytes
- Lines
- 343
- Domain
- Repository Root And Misc
- Bucket
- include
- Inferred role
- Repository Root And Misc: implementation source
- Status
- source implementation candidate
Why This File Exists
Top-level or miscellaneous repository surface. Use this as map coverage unless a later manual pass promotes the file into a deeper subsystem dossier.
- Top-level or miscellaneous repository surface. Use this as map coverage unless a later manual pass promotes the file into a deeper subsystem dossier.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/types.h
Detected Declarations
struct erase_info_userstruct erase_info_user64struct mtd_oob_bufstruct mtd_oob_buf64struct mtd_write_reqstruct mtd_read_req_ecc_statsstruct mtd_read_reqstruct mtd_info_userstruct region_info_userstruct otp_infostruct nand_oobinfostruct nand_oobfreestruct nand_ecclayout_userstruct mtd_ecc_statsenum mtd_file_modesfunction mtd_type_is_nand_user
Annotated Snippet
struct erase_info_user {
__u32 start;
__u32 length;
};
struct erase_info_user64 {
__u64 start;
__u64 length;
};
struct mtd_oob_buf {
__u32 start;
__u32 length;
unsigned char __user *ptr;
};
struct mtd_oob_buf64 {
__u64 start;
__u32 pad;
__u32 length;
__u64 usr_ptr;
};
/**
* MTD operation modes
*
* @MTD_OPS_PLACE_OOB: OOB data are placed at the given offset (default)
* @MTD_OPS_AUTO_OOB: OOB data are automatically placed at the free areas
* which are defined by the internal ecclayout
* @MTD_OPS_RAW: data are transferred as-is, with no error correction;
* this mode implies %MTD_OPS_PLACE_OOB
*
* These modes can be passed to ioctl(MEMWRITE) and ioctl(MEMREAD); they are
* also used internally. See notes on "MTD file modes" for discussion on
* %MTD_OPS_RAW vs. %MTD_FILE_MODE_RAW.
*/
enum {
MTD_OPS_PLACE_OOB = 0,
MTD_OPS_AUTO_OOB = 1,
MTD_OPS_RAW = 2,
};
/**
* struct mtd_write_req - data structure for requesting a write operation
*
* @start: start address
* @len: length of data buffer (only lower 32 bits are used)
* @ooblen: length of OOB buffer (only lower 32 bits are used)
* @usr_data: user-provided data buffer
* @usr_oob: user-provided OOB buffer
* @mode: MTD mode (see "MTD operation modes")
* @padding: reserved, must be set to 0
*
* This structure supports ioctl(MEMWRITE) operations, allowing data and/or OOB
* writes in various modes. To write to OOB-only, set @usr_data == NULL, and to
* write data-only, set @usr_oob == NULL. However, setting both @usr_data and
* @usr_oob to NULL is not allowed.
*/
struct mtd_write_req {
__u64 start;
__u64 len;
__u64 ooblen;
__u64 usr_data;
__u64 usr_oob;
__u8 mode;
__u8 padding[7];
};
/**
* struct mtd_read_req_ecc_stats - ECC statistics for a read operation
*
* @uncorrectable_errors: the number of uncorrectable errors that happened
* during the read operation
* @corrected_bitflips: the number of bitflips corrected during the read
* operation
* @max_bitflips: the maximum number of bitflips detected in any single ECC
* step for the data read during the operation; this information
* can be used to decide whether the data stored in a specific
* region of the MTD device should be moved somewhere else to
* avoid data loss.
*/
struct mtd_read_req_ecc_stats {
__u32 uncorrectable_errors;
__u32 corrected_bitflips;
__u32 max_bitflips;
};
/**
* struct mtd_read_req - data structure for requesting a read operation
*
Annotation
- Immediate include surface: `linux/types.h`.
- Detected declarations: `struct erase_info_user`, `struct erase_info_user64`, `struct mtd_oob_buf`, `struct mtd_oob_buf64`, `struct mtd_write_req`, `struct mtd_read_req_ecc_stats`, `struct mtd_read_req`, `struct mtd_info_user`, `struct region_info_user`, `struct otp_info`.
- Atlas domain: Repository Root And Misc / include.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.