arch/arm64/kernel/acpi_parking_protocol.c
Source file repositories/reference/linux-study-clean/arch/arm64/kernel/acpi_parking_protocol.c
File Facts
- System
- Linux kernel
- Corpus path
arch/arm64/kernel/acpi_parking_protocol.c- Extension
.c- Size
- 3595 bytes
- Lines
- 133
- Domain
- Architecture Layer
- Bucket
- arch/arm64
- Inferred role
- Architecture Layer: implementation source
- Status
- source 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 or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/acpi.hlinux/mm.hlinux/types.hasm/cpu_ops.h
Detected Declarations
struct parking_protocol_mailboxstruct cpu_mailbox_entryfunction acpi_set_mailbox_entryfunction acpi_parking_protocol_validfunction acpi_parking_protocol_cpu_initfunction acpi_parking_protocol_cpu_preparefunction acpi_parking_protocol_cpu_bootfunction acpi_parking_protocol_cpu_postboot
Annotated Snippet
struct parking_protocol_mailbox {
__le32 cpu_id;
__le32 reserved;
__le64 entry_point;
};
struct cpu_mailbox_entry {
struct parking_protocol_mailbox __iomem *mailbox;
phys_addr_t mailbox_addr;
u8 version;
u8 gic_cpu_id;
};
static struct cpu_mailbox_entry cpu_mailbox_entries[NR_CPUS];
void __init acpi_set_mailbox_entry(int cpu,
struct acpi_madt_generic_interrupt *p)
{
struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
cpu_entry->mailbox_addr = p->parked_address;
cpu_entry->version = p->parking_version;
cpu_entry->gic_cpu_id = p->cpu_interface_number;
}
bool acpi_parking_protocol_valid(int cpu)
{
struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
return cpu_entry->mailbox_addr && cpu_entry->version;
}
static int acpi_parking_protocol_cpu_init(unsigned int cpu)
{
pr_debug("%s: ACPI parked addr=%llx\n", __func__,
cpu_mailbox_entries[cpu].mailbox_addr);
return 0;
}
static int acpi_parking_protocol_cpu_prepare(unsigned int cpu)
{
return 0;
}
static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
{
struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
struct parking_protocol_mailbox __iomem *mailbox;
u32 cpu_id;
/*
* Map mailbox memory with attribute device nGnRE (ie ioremap -
* this deviates from the parking protocol specifications since
* the mailboxes are required to be mapped nGnRnE; the attribute
* discrepancy is harmless insofar as the protocol specification
* is concerned).
* If the mailbox is mistakenly allocated in the linear mapping
* by FW ioremap will fail since the mapping will be prevented
* by the kernel (it clashes with the linear mapping attributes
* specifications).
*/
mailbox = ioremap(cpu_entry->mailbox_addr, sizeof(*mailbox));
if (!mailbox)
return -EIO;
cpu_id = readl_relaxed(&mailbox->cpu_id);
/*
* Check if firmware has set-up the mailbox entry properly
* before kickstarting the respective cpu.
*/
if (cpu_id != ~0U) {
iounmap(mailbox);
return -ENXIO;
}
/*
* stash the mailbox address mapping to use it for further FW
* checks in the postboot method
*/
cpu_entry->mailbox = mailbox;
/*
* We write the entry point and cpu id as LE regardless of the
* native endianness of the kernel. Therefore, any boot-loaders
* that read this address need to convert this address to the
* Boot-Loader's endianness before jumping.
*/
writeq_relaxed(__pa_symbol(secondary_entry),
&mailbox->entry_point);
Annotation
- Immediate include surface: `linux/acpi.h`, `linux/mm.h`, `linux/types.h`, `asm/cpu_ops.h`.
- Detected declarations: `struct parking_protocol_mailbox`, `struct cpu_mailbox_entry`, `function acpi_set_mailbox_entry`, `function acpi_parking_protocol_valid`, `function acpi_parking_protocol_cpu_init`, `function acpi_parking_protocol_cpu_prepare`, `function acpi_parking_protocol_cpu_boot`, `function acpi_parking_protocol_cpu_postboot`.
- Atlas domain: Architecture Layer / arch/arm64.
- 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.