drivers/net/ipa/ipa.h
Source file repositories/reference/linux-study-clean/drivers/net/ipa/ipa.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/net/ipa/ipa.h- Extension
.h- Size
- 5737 bytes
- Lines
- 168
- Domain
- Driver Families
- Bucket
- drivers/net
- 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.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/notifier.hlinux/types.hgsi.hipa_endpoint.hipa_mem.hipa_qmi.hipa_version.h
Detected Declarations
struct net_devicestruct ipa_interruptstruct ipa_powerstruct ipa_smp2pstruct ipa
Annotated Snippet
struct ipa {
struct gsi gsi;
enum ipa_version version;
struct device *dev;
struct completion completion;
struct notifier_block nb;
void *notifier;
struct ipa_smp2p *smp2p;
struct ipa_power *power;
dma_addr_t table_addr;
__le64 *table_virt;
u32 route_count;
u32 modem_route_count;
u32 filter_count;
struct ipa_interrupt *interrupt;
bool uc_powered;
bool uc_loaded;
void __iomem *reg_virt;
const struct regs *regs;
dma_addr_t mem_addr;
void *mem_virt;
u32 mem_offset;
u32 mem_size;
u32 mem_count;
const struct ipa_mem *mem;
unsigned long imem_iova;
size_t imem_size;
unsigned long smem_iova;
size_t smem_size;
dma_addr_t zero_addr;
void *zero_virt;
size_t zero_size;
/* Bitmaps indicating endpoint state */
u32 endpoint_count;
u32 available_count;
unsigned long *defined; /* Defined in configuration data */
unsigned long *available; /* Supported by hardware */
u64 filtered; /* Support filtering (AP and modem) */
unsigned long *set_up;
unsigned long *enabled;
u32 modem_tx_count;
struct ipa_endpoint endpoint[IPA_ENDPOINT_MAX];
struct ipa_endpoint *channel_map[GSI_CHANNEL_COUNT_MAX];
struct ipa_endpoint *name_map[IPA_ENDPOINT_COUNT];
bool setup_complete;
atomic_t modem_state; /* enum ipa_modem_state */
struct net_device *modem_netdev;
struct ipa_qmi qmi;
};
/**
* ipa_setup() - Perform IPA setup
* @ipa: IPA pointer
*
* IPA initialization is broken into stages: init; config; and setup.
* (These have inverses exit, deconfig, and teardown.)
*
* Activities performed at the init stage can be done without requiring
* any access to IPA hardware. Activities performed at the config stage
* require IPA power, because they involve access to IPA registers.
* The setup stage is performed only after the GSI hardware is ready
* (more on this below). The setup stage allows the AP to perform
* more complex initialization by issuing "immediate commands" using
* a special interface to the IPA.
*
* This function, @ipa_setup(), starts the setup stage.
*
* In order for the GSI hardware to be functional it needs firmware to be
* loaded (in addition to some other low-level initialization). This early
* GSI initialization can be done either by Trust Zone on the AP or by the
* modem.
*
* If it's done by Trust Zone, the AP loads the GSI firmware and supplies
* it to Trust Zone to verify and install. When this completes, if
* verification was successful, the GSI layer is ready and ipa_setup()
* implements the setup phase of initialization.
*
* If the modem performs early GSI initialization, the AP needs to know
* when this has occurred. An SMP2P interrupt is used for this purpose,
Annotation
- Immediate include surface: `linux/notifier.h`, `linux/types.h`, `gsi.h`, `ipa_endpoint.h`, `ipa_mem.h`, `ipa_qmi.h`, `ipa_version.h`.
- Detected declarations: `struct net_device`, `struct ipa_interrupt`, `struct ipa_power`, `struct ipa_smp2p`, `struct ipa`.
- Atlas domain: Driver Families / drivers/net.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
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.