drivers/mtd/spi-nor/core.h
Source file repositories/reference/linux-study-clean/drivers/mtd/spi-nor/core.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/mtd/spi-nor/core.h- Extension
.h- Size
- 26692 bytes
- Lines
- 736
- Domain
- Driver Families
- Bucket
- drivers/mtd
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
sfdp.h
Detected Declarations
struct spi_nor_read_commandstruct spi_nor_pp_commandstruct spi_nor_erase_typestruct spi_nor_erase_commandstruct spi_nor_erase_regionstruct spi_nor_erase_mapstruct spi_nor_locking_opsstruct spi_nor_otp_organizationstruct spi_nor_otp_opsstruct spi_nor_otpstruct spi_nor_flash_parameterstruct spi_nor_fixupsstruct spi_nor_idstruct flash_infostruct spi_nor_manufacturerstruct sfdpenum spi_nor_option_flagsenum spi_nor_read_command_indexenum spi_nor_pp_command_indexfunction spi_nor_needs_sfdpfunction spi_nor_debugfs_register
Annotated Snippet
struct spi_nor_read_command {
u8 num_mode_clocks;
u8 num_wait_states;
u8 opcode;
enum spi_nor_protocol proto;
};
struct spi_nor_pp_command {
u8 opcode;
enum spi_nor_protocol proto;
};
enum spi_nor_read_command_index {
SNOR_CMD_READ,
SNOR_CMD_READ_FAST,
SNOR_CMD_READ_1_1_1_DTR,
/* Dual SPI */
SNOR_CMD_READ_1_1_2,
SNOR_CMD_READ_1_2_2,
SNOR_CMD_READ_2_2_2,
SNOR_CMD_READ_1_2_2_DTR,
/* Quad SPI */
SNOR_CMD_READ_1_1_4,
SNOR_CMD_READ_1_4_4,
SNOR_CMD_READ_4_4_4,
SNOR_CMD_READ_1_4_4_DTR,
/* Octal SPI */
SNOR_CMD_READ_1_1_8,
SNOR_CMD_READ_1_8_8,
SNOR_CMD_READ_8_8_8,
SNOR_CMD_READ_1_8_8_DTR,
SNOR_CMD_READ_8_8_8_DTR,
SNOR_CMD_READ_MAX
};
enum spi_nor_pp_command_index {
SNOR_CMD_PP,
/* Quad SPI */
SNOR_CMD_PP_1_1_4,
SNOR_CMD_PP_1_4_4,
SNOR_CMD_PP_4_4_4,
/* Octal SPI */
SNOR_CMD_PP_1_1_8,
SNOR_CMD_PP_1_8_8,
SNOR_CMD_PP_8_8_8,
SNOR_CMD_PP_8_8_8_DTR,
SNOR_CMD_PP_MAX
};
/**
* struct spi_nor_erase_type - Structure to describe a SPI NOR erase type
* @size: the size of the sector/block erased by the erase type.
* JEDEC JESD216B imposes erase sizes to be a power of 2.
* @size_shift: @size is a power of 2, the shift is stored in
* @size_shift.
* @size_mask: the size mask based on @size_shift.
* @opcode: the SPI command op code to erase the sector/block.
* @idx: Erase Type index as sorted in the Basic Flash Parameter
* Table. It will be used to synchronize the supported
* Erase Types with the ones identified in the SFDP
* optional tables.
*/
struct spi_nor_erase_type {
u32 size;
u32 size_shift;
u32 size_mask;
u8 opcode;
u8 idx;
};
/**
* struct spi_nor_erase_command - Used for non-uniform erases
* The structure is used to describe a list of erase commands to be executed
* once we validate that the erase can be performed. The elements in the list
* are run-length encoded.
* @list: for inclusion into the list of erase commands.
* @count: how many times the same erase command should be
* consecutively used.
* @size: the size of the sector/block erased by the command.
* @opcode: the SPI command op code to erase the sector/block.
*/
struct spi_nor_erase_command {
struct list_head list;
Annotation
- Immediate include surface: `sfdp.h`.
- Detected declarations: `struct spi_nor_read_command`, `struct spi_nor_pp_command`, `struct spi_nor_erase_type`, `struct spi_nor_erase_command`, `struct spi_nor_erase_region`, `struct spi_nor_erase_map`, `struct spi_nor_locking_ops`, `struct spi_nor_otp_organization`, `struct spi_nor_otp_ops`, `struct spi_nor_otp`.
- Atlas domain: Driver Families / drivers/mtd.
- 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.