include/linux/firmware/intel/stratix10-smc.h
Source file repositories/reference/linux-study-clean/include/linux/firmware/intel/stratix10-smc.h
File Facts
- System
- Linux kernel
- Corpus path
include/linux/firmware/intel/stratix10-smc.h- Extension
.h- Size
- 21319 bytes
- Lines
- 735
- 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.
Dependency Surface
linux/arm-smccc.hlinux/bitops.h
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
#ifndef __STRATIX10_SMC_H
#define __STRATIX10_SMC_H
#include <linux/arm-smccc.h>
#include <linux/bitops.h>
/**
* This file defines the Secure Monitor Call (SMC) message protocol used for
* service layer driver in normal world (EL1) to communicate with secure
* monitor software in Secure Monitor Exception Level 3 (EL3).
*
* This file is shared with secure firmware (FW) which is out of kernel tree.
*
* An ARM SMC instruction takes a function identifier and up to 6 64-bit
* register values as arguments, and can return up to 4 64-bit register
* value. The operation of the secure monitor is determined by the parameter
* values passed in through registers.
*
* EL1 and EL3 communicates pointer as physical address rather than the
* virtual address.
*
* Functions specified by ARM SMC Calling convention:
*
* FAST call executes atomic operations, returns when the requested operation
* has completed.
* STD call starts a operation which can be preempted by a non-secure
* interrupt. The call can return before the requested operation has
* completed.
*
* a0..a7 is used as register names in the descriptions below, on arm32
* that translates to r0..r7 and on arm64 to w0..w7.
*/
/**
* @func_num: function ID
*/
#define INTEL_SIP_SMC_STD_CALL_VAL(func_num) \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_SMC_64, \
ARM_SMCCC_OWNER_SIP, (func_num))
#define INTEL_SIP_SMC_FAST_CALL_VAL(func_num) \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \
ARM_SMCCC_OWNER_SIP, (func_num))
#define INTEL_SIP_SMC_ASYNC_VAL(func_name) \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_SMC_64, \
ARM_SMCCC_OWNER_SIP, (func_name))
/**
* Return values in INTEL_SIP_SMC_* call
*
* INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION:
* Secure monitor software doesn't recognize the request.
*
* INTEL_SIP_SMC_STATUS_OK:
* Secure monitor software accepts the service client's request.
*
* INTEL_SIP_SMC_STATUS_BUSY:
* Secure monitor software is still processing service client's request.
*
* INTEL_SIP_SMC_STATUS_REJECTED:
* Secure monitor software reject the service client's request.
*
* INTEL_SIP_SMC_STATUS_ERROR:
* There is error during the process of service request.
*
* INTEL_SIP_SMC_RSU_ERROR:
* There is error during the process of remote status update request.
*/
#define INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION 0xFFFFFFFF
#define INTEL_SIP_SMC_STATUS_OK 0x0
#define INTEL_SIP_SMC_STATUS_BUSY 0x1
#define INTEL_SIP_SMC_STATUS_REJECTED 0x2
#define INTEL_SIP_SMC_STATUS_ERROR 0x4
#define INTEL_SIP_SMC_RSU_ERROR 0x7
/**
* Request INTEL_SIP_SMC_FPGA_CONFIG_START
*
* Sync call used by service driver at EL1 to request the FPGA in EL3 to
* be prepare to receive a new configuration.
*
* Call register usage:
* a0: INTEL_SIP_SMC_FPGA_CONFIG_START.
* a1: flag for full or partial configuration. 0 for full and 1 for partial
* configuration.
* a2-7: not used.
*
* Return status:
* a0: INTEL_SIP_SMC_STATUS_OK, or INTEL_SIP_SMC_STATUS_ERROR.
Annotation
- Immediate include surface: `linux/arm-smccc.h`, `linux/bitops.h`.
- Atlas domain: Core OS / Core Kernel Interface.
- 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.