include/linux/platform_data/cros_ec_commands.h
Source file repositories/reference/linux-study-clean/include/linux/platform_data/cros_ec_commands.h
File Facts
- System
- Linux kernel
- Corpus path
include/linux/platform_data/cros_ec_commands.h- Extension
.h- Size
- 193476 bytes
- Lines
- 6669
- 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.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/bits.hlinux/types.h
Detected Declarations
struct ec_lpc_host_argsstruct ec_host_requeststruct ec_host_responsestruct ec_host_request4struct ec_host_response4struct ec_response_proto_versionstruct ec_params_hellostruct ec_response_hellostruct ec_response_get_versionstruct ec_params_read_teststruct ec_response_read_teststruct ec_response_get_chip_infostruct ec_response_board_versionstruct ec_params_read_memmapstruct ec_params_get_cmd_versionsstruct ec_params_get_cmd_versions_v1struct ec_response_get_cmd_versionsstruct ec_response_get_comms_statusstruct ec_params_test_protocolstruct ec_response_test_protocolstruct ec_response_get_protocol_infostruct ec_params_get_set_valuestruct ec_response_get_set_valuestruct ec_response_get_featuresstruct ec_sku_id_infostruct ec_response_flash_infostruct ec_response_flash_info_1struct ec_params_flash_info_2struct ec_flash_bankstruct ec_response_flash_info_2struct ec_params_flash_readstruct ec_params_flash_writestruct ec_params_flash_erasestruct ec_params_flash_erase_v1struct ec_params_flash_protectstruct ec_response_flash_protectstruct ec_params_flash_region_infostruct ec_response_flash_region_infostruct ec_params_vbnvcontextstruct ec_response_vbnvcontextstruct ec_response_flash_spi_infostruct ec_params_flash_selectstruct ec_response_pwm_get_fan_rpmstruct ec_params_pwm_set_fan_target_rpm_v0struct ec_params_pwm_set_fan_target_rpm_v1struct ec_response_pwm_get_keyboard_backlightstruct ec_params_pwm_set_keyboard_backlightstruct ec_params_pwm_set_fan_duty_v0
Annotated Snippet
struct ec_lpc_host_args {
uint8_t flags;
uint8_t command_version;
uint8_t data_size;
uint8_t checksum;
} __ec_align4;
/* Flags for ec_lpc_host_args.flags */
/*
* Args are from host. Data area at EC_LPC_ADDR_HOST_PARAM contains command
* params.
*
* If EC gets a command and this flag is not set, this is an old-style command.
* Command version is 0 and params from host are at EC_LPC_ADDR_OLD_PARAM with
* unknown length. EC must respond with an old-style response (that is,
* without setting EC_HOST_ARGS_FLAG_TO_HOST).
*/
#define EC_HOST_ARGS_FLAG_FROM_HOST 0x01
/*
* Args are from EC. Data area at EC_LPC_ADDR_HOST_PARAM contains response.
*
* If EC responds to a command and this flag is not set, this is an old-style
* response. Command version is 0 and response data from EC is at
* EC_LPC_ADDR_OLD_PARAM with unknown length.
*/
#define EC_HOST_ARGS_FLAG_TO_HOST 0x02
/*****************************************************************************/
/*
* Byte codes returned by EC over SPI interface.
*
* These can be used by the AP to debug the EC interface, and to determine
* when the EC is not in a state where it will ever get around to responding
* to the AP.
*
* Example of sequence of bytes read from EC for a current good transfer:
* 1. - - AP asserts chip select (CS#)
* 2. EC_SPI_OLD_READY - AP sends first byte(s) of request
* 3. - - EC starts handling CS# interrupt
* 4. EC_SPI_RECEIVING - AP sends remaining byte(s) of request
* 5. EC_SPI_PROCESSING - EC starts processing request; AP is clocking in
* bytes looking for EC_SPI_FRAME_START
* 6. - - EC finishes processing and sets up response
* 7. EC_SPI_FRAME_START - AP reads frame byte
* 8. (response packet) - AP reads response packet
* 9. EC_SPI_PAST_END - Any additional bytes read by AP
* 10 - - AP deasserts chip select
* 11 - - EC processes CS# interrupt and sets up DMA for
* next request
*
* If the AP is waiting for EC_SPI_FRAME_START and sees any value other than
* the following byte values:
* EC_SPI_OLD_READY
* EC_SPI_RX_READY
* EC_SPI_RECEIVING
* EC_SPI_PROCESSING
*
* Then the EC found an error in the request, or was not ready for the request
* and lost data. The AP should give up waiting for EC_SPI_FRAME_START,
* because the EC is unable to tell when the AP is done sending its request.
*/
/*
* Framing byte which precedes a response packet from the EC. After sending a
* request, the AP will clock in bytes until it sees the framing byte, then
* clock in the response packet.
*/
#define EC_SPI_FRAME_START 0xec
/*
* Padding bytes which are clocked out after the end of a response packet.
*/
#define EC_SPI_PAST_END 0xed
/*
* EC is ready to receive, and has ignored the byte sent by the AP. EC expects
* that the AP will send a valid packet header (starting with
* EC_COMMAND_PROTOCOL_3) in the next 32 bytes.
*/
#define EC_SPI_RX_READY 0xf8
/*
* EC has started receiving the request from the AP, but hasn't started
* processing it yet.
*/
#define EC_SPI_RECEIVING 0xf9
/* EC has received the entire request from the AP and is processing it. */
#define EC_SPI_PROCESSING 0xfa
Annotation
- Immediate include surface: `linux/bits.h`, `linux/types.h`.
- Detected declarations: `struct ec_lpc_host_args`, `struct ec_host_request`, `struct ec_host_response`, `struct ec_host_request4`, `struct ec_host_response4`, `struct ec_response_proto_version`, `struct ec_params_hello`, `struct ec_response_hello`, `struct ec_response_get_version`, `struct ec_params_read_test`.
- 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.