include/linux/spi/spi-mem.h
Source file repositories/reference/linux-study-clean/include/linux/spi/spi-mem.h
File Facts
- System
- Linux kernel
- Corpus path
include/linux/spi/spi-mem.h- Extension
.h- Size
- 16751 bytes
- Lines
- 510
- Domain
- Core OS
- Bucket
- Core Kernel Interface
- Inferred role
- Core OS: implementation source
- Status
- source implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/spi/spi.h
Detected Declarations
struct spi_mem_opstruct spi_mem_dirmap_infostruct spi_mem_dirmap_descstruct spi_memstruct spi_controller_mem_opsstruct spi_controller_mem_capsstruct spi_mem_driverenum spi_mem_data_dirfunction spi_mem_set_drvdatafunction spi_mem_get_drvdatafunction spi_controller_dma_map_mem_op_datafunction spi_controller_dma_unmap_mem_op_data
Annotated Snippet
struct spi_mem_op {
struct {
u8 nbytes;
u8 buswidth;
u8 dtr : 1;
u8 __pad : 7;
u16 opcode;
} cmd;
struct {
u8 nbytes;
u8 buswidth;
u8 dtr : 1;
u8 __pad : 7;
u64 val;
} addr;
struct {
u8 nbytes;
u8 buswidth;
u8 dtr : 1;
u8 __pad : 7;
} dummy;
struct {
u8 buswidth;
u8 dtr : 1;
u8 ecc : 1;
u8 swap16 : 1;
u8 __pad : 5;
enum spi_mem_data_dir dir;
unsigned int nbytes;
union {
void *in;
const void *out;
} buf;
} data;
unsigned int max_freq;
};
#define SPI_MEM_OP(__cmd, __addr, __dummy, __data, ...) \
{ \
.cmd = __cmd, \
.addr = __addr, \
.dummy = __dummy, \
.data = __data, \
__VA_ARGS__ \
}
/**
* struct spi_mem_dirmap_info - Direct mapping information
* @op_tmpl: operation template that should be used by the direct mapping when
* the memory device is accessed
* @secondary_op_tmpl: secondary template, may be used as an alternative to the
* primary template (decided by the upper layer)
* @offset: absolute offset this direct mapping is pointing to
* @length: length in byte of this direct mapping
*
* These information are used by the controller specific implementation to know
* the portion of memory that is directly mapped and the spi_mem_op that should
* be used to access the device.
* A direct mapping is only valid for one direction (read or write) and this
* direction is directly encoded in the ->op_tmpl.data.dir field.
*/
struct spi_mem_dirmap_info {
struct spi_mem_op *op_tmpl;
struct spi_mem_op primary_op_tmpl;
struct spi_mem_op secondary_op_tmpl;
u64 offset;
u64 length;
};
/**
* struct spi_mem_dirmap_desc - Direct mapping descriptor
* @mem: the SPI memory device this direct mapping is attached to
* @info: information passed at direct mapping creation time
* @nodirmap: set to 1 if the SPI controller does not implement
* ->mem_ops->dirmap_create() or when this function returned an
* error. If @nodirmap is true, all spi_mem_dirmap_{read,write}()
* calls will use spi_mem_exec_op() to access the memory. This is a
* degraded mode that allows spi_mem drivers to use the same code
* no matter whether the controller supports direct mapping or not
* @priv: field pointing to controller specific data
*
* Common part of a direct mapping descriptor. This object is created by
* spi_mem_dirmap_create() and controller implementation of ->create_dirmap()
* can create/attach direct mapping resources to the descriptor in the ->priv
* field.
*/
Annotation
- Immediate include surface: `linux/spi/spi.h`.
- Detected declarations: `struct spi_mem_op`, `struct spi_mem_dirmap_info`, `struct spi_mem_dirmap_desc`, `struct spi_mem`, `struct spi_controller_mem_ops`, `struct spi_controller_mem_caps`, `struct spi_mem_driver`, `enum spi_mem_data_dir`, `function spi_mem_set_drvdata`, `function spi_mem_get_drvdata`.
- Atlas domain: Core OS / Core Kernel Interface.
- Implementation status: source implementation candidate.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
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.