arch/arm/mach-bcm/bcm_kona_smc.c
Source file repositories/reference/linux-study-clean/arch/arm/mach-bcm/bcm_kona_smc.c
File Facts
- System
- Linux kernel
- Corpus path
arch/arm/mach-bcm/bcm_kona_smc.c- Extension
.c- Size
- 4352 bytes
- Lines
- 159
- Domain
- Architecture Layer
- Bucket
- arch/arm
- 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/smp.hlinux/io.hlinux/ioport.hasm/cacheflush.hlinux/of_address.hbcm_kona_smc.h
Detected Declarations
struct bcm_kona_smc_datafunction bcm_kona_smc_initfunction bcm_kona_do_smcfunction __bcm_kona_smcfunction bcm_kona_smc
Annotated Snippet
struct bcm_kona_smc_data {
unsigned service_id;
unsigned arg0;
unsigned arg1;
unsigned arg2;
unsigned arg3;
unsigned result;
};
static const struct of_device_id bcm_kona_smc_ids[] __initconst = {
{.compatible = "brcm,kona-smc"},
{.compatible = "bcm,kona-smc"}, /* deprecated name */
{},
};
/* Map in the args buffer area */
int __init bcm_kona_smc_init(void)
{
struct device_node *node;
struct resource res;
int ret;
/* Read buffer addr and size from the device tree node */
node = of_find_matching_node(NULL, bcm_kona_smc_ids);
if (!node)
return -ENODEV;
ret = of_address_to_resource(node, 0, &res);
of_node_put(node);
if (ret)
return -EINVAL;
bcm_smc_buffer = ioremap(res.start, resource_size(&res));
if (!bcm_smc_buffer)
return -ENOMEM;
bcm_smc_buffer_phys = res.start;
pr_info("Kona Secure API initialized\n");
return 0;
}
/*
* int bcm_kona_do_smc(u32 service_id, u32 buffer_addr)
*
* Only core 0 can run the secure monitor code. If an "smc" request
* is initiated on a different core it must be redirected to core 0
* for execution. We rely on the caller to handle this.
*
* Each "smc" request supplies a service id and the address of a
* buffer containing parameters related to the service to be
* performed. A flags value defines the behavior of the level 2
* cache and interrupt handling while the secure monitor executes.
*
* Parameters to the "smc" request are passed in r4-r6 as follows:
* r4 service id
* r5 flags (SEC_ROM_*)
* r6 physical address of buffer with other parameters
*
* Execution of an "smc" request produces two distinct results.
*
* First, the secure monitor call itself (regardless of the specific
* service request) can succeed, or can produce an error. When an
* "smc" request completes this value is found in r12; it should
* always be SEC_EXIT_NORMAL.
*
* In addition, the particular service performed produces a result.
* The values that should be expected depend on the service. We
* therefore return this value to the caller, so it can handle the
* request result appropriately. This result value is found in r0
* when the "smc" request completes.
*/
static int bcm_kona_do_smc(u32 service_id, u32 buffer_phys)
{
register u32 ip asm("ip"); /* Also called r12 */
register u32 r0 asm("r0");
register u32 r4 asm("r4");
register u32 r5 asm("r5");
register u32 r6 asm("r6");
r4 = service_id;
r5 = 0x3; /* Keep IRQ and FIQ off in SM */
r6 = buffer_phys;
asm volatile (
/* Make sure we got the registers we want */
__asmeq("%0", "ip")
__asmeq("%1", "r0")
__asmeq("%2", "r4")
__asmeq("%3", "r5")
Annotation
- Immediate include surface: `linux/smp.h`, `linux/io.h`, `linux/ioport.h`, `asm/cacheflush.h`, `linux/of_address.h`, `bcm_kona_smc.h`.
- Detected declarations: `struct bcm_kona_smc_data`, `function bcm_kona_smc_init`, `function bcm_kona_do_smc`, `function __bcm_kona_smc`, `function bcm_kona_smc`.
- Atlas domain: Architecture Layer / arch/arm.
- 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.