arch/arm/include/asm/ecard.h

File Facts

System

Linux kernel

Corpus path

arch/arm/include/asm/ecard.h

Extension

.h

Size

6125 bytes

Lines

220

Domain

Architecture Layer

Bucket

arch/arm

Inferred role

Architecture Layer: operation-table or driver-model contract

Status

pattern implementation candidate

Why This File Exists

CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.

• CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
• Defines an operation table; this is where Linux turns generic core objects into subsystem-specific behavior.
• 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

• No C-style include directives detected by the generator.

Detected Declarations

• struct ecard_id
• struct in_ecid
• struct expansion_card
• struct in_chunk_dir
• struct ecard_driver

Annotated Snippet

extern const struct bus_type ecard_bus_type;

#define ECARD_DEV(_d)	container_of((_d), struct expansion_card, dev)

struct ecard_driver {
	int			(*probe)(struct expansion_card *, const struct ecard_id *id);
	void			(*remove)(struct expansion_card *);
	void			(*shutdown)(struct expansion_card *);
	const struct ecard_id	*id_table;
	unsigned int		id;
	struct device_driver	drv;
};

#define ECARD_DRV(_d)	container_of((_d), struct ecard_driver, drv)

#define ecard_set_drvdata(ec,data)	dev_set_drvdata(&(ec)->dev, (data))
#define ecard_get_drvdata(ec)		dev_get_drvdata(&(ec)->dev)

int ecard_register_driver(struct ecard_driver *);
void ecard_remove_driver(struct ecard_driver *);

#endif

Annotation

• Detected declarations: `struct ecard_id`, `struct in_ecid`, `struct expansion_card`, `struct in_chunk_dir`, `struct ecard_driver`.
• Atlas domain: Architecture Layer / arch/arm.
• Implementation status: pattern 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.