drivers/cxl/core/mbox.c
Source file repositories/reference/linux-study-clean/drivers/cxl/core/mbox.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/cxl/core/mbox.c- Extension
.c- Size
- 42977 bytes
- Lines
- 1559
- Domain
- Driver Families
- Bucket
- drivers/cxl
- Inferred role
- Driver Families: exported/initcall integration point
- Status
- integration 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.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Touches user memory; correctness depends on fault-safe copying and privilege boundary handling.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/security.hlinux/debugfs.hlinux/ktime.hlinux/mutex.hlinux/unaligned.hcxlpci.hcxlmem.hcxl.hcore.htrace.hmce.h
Detected Declarations
struct cxl_get_security_outputfunction cxl_is_security_commandfunction cxl_set_security_cmd_enabledfunction cxl_is_poison_commandfunction cxl_set_poison_cmd_enabledfunction cxl_internal_send_cmdfunction cxl_mem_raw_command_allowedfunction cxl_payload_from_user_allowedfunction cxl_mbox_cmd_ctorfunction cxl_mbox_cmd_dtorfunction cxl_to_mem_cmd_rawfunction cxl_to_mem_cmdfunction cxl_validate_cmd_from_userfunction cxl_query_cmdfunction handle_mailbox_cmd_from_userfunction cxl_send_cmdfunction cxl_xfer_logfunction check_features_opcodesfunction set_features_capfunction cxl_walk_celfunction cxl_enumerate_cmdsfunction cxl_event_trace_recordfunction __cxl_event_trace_recordfunction cxl_clear_event_recordfunction cxl_mem_get_records_logfunction cxl_mem_get_event_recordsfunction cxl_mem_get_partition_infofunction cxl_dev_state_identifyfunction __cxl_mem_sanitizefunction cxl_mem_sanitizefunction add_partfunction cxl_mem_dpa_fetchfunction cxl_get_dirty_countfunction cxl_arm_dirty_shutdownfunction cxl_set_timestampfunction cxl_mem_get_poisonfunction free_poison_buffunction cxl_poison_alloc_buffunction cxl_poison_state_initfunction cxl_mailbox_initfunction cxl_mbox_init
Annotated Snippet
struct cxl_get_security_output {
__le32 flags;
} out;
struct cxl_mbox_cmd sec_cmd = {
.opcode = CXL_MBOX_OP_GET_SECURITY_STATE,
.payload_out = &out,
.size_out = sizeof(out),
};
struct cxl_mbox_cmd mbox_cmd = { .opcode = cmd };
if (cmd != CXL_MBOX_OP_SANITIZE && cmd != CXL_MBOX_OP_SECURE_ERASE)
return -EINVAL;
rc = cxl_internal_send_cmd(cxl_mbox, &sec_cmd);
if (rc < 0) {
dev_err(cxl_mbox->host, "Failed to get security state : %d", rc);
return rc;
}
/*
* Prior to using these commands, any security applied to
* the user data areas of the device shall be DISABLED (or
* UNLOCKED for secure erase case).
*/
sec_out = le32_to_cpu(out.flags);
if (sec_out & CXL_PMEM_SEC_STATE_USER_PASS_SET)
return -EINVAL;
if (cmd == CXL_MBOX_OP_SECURE_ERASE &&
sec_out & CXL_PMEM_SEC_STATE_LOCKED)
return -EINVAL;
rc = cxl_internal_send_cmd(cxl_mbox, &mbox_cmd);
if (rc < 0) {
dev_err(cxl_mbox->host, "Failed to sanitize device : %d", rc);
return rc;
}
return 0;
}
/**
* cxl_mem_sanitize() - Send a sanitization command to the device.
* @cxlmd: The device for the operation
* @cmd: The specific sanitization command opcode
*
* Return: 0 if the command was executed successfully, regardless of
* whether or not the actual security operation is done in the background,
* such as for the Sanitize case.
* Error return values can be the result of the mailbox command, -EINVAL
* when security requirements are not met or invalid contexts, or -EBUSY
* if the sanitize operation is already in flight.
*
* See CXL 3.0 @8.2.9.8.5.1 Sanitize and @8.2.9.8.5.2 Secure Erase.
*/
int cxl_mem_sanitize(struct cxl_memdev *cxlmd, u16 cmd)
{
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlmd->cxlds);
struct cxl_port *endpoint;
/* synchronize with cxl_mem_probe() and decoder write operations */
guard(device)(&cxlmd->dev);
endpoint = cxlmd->endpoint;
guard(rwsem_read)(&cxl_rwsem.region);
/*
* Require an endpoint to be safe otherwise the driver can not
* be sure that the device is unmapped.
*/
if (cxlmd->dev.driver && cxl_num_decoders_committed(endpoint) == 0)
return __cxl_mem_sanitize(mds, cmd);
return -EBUSY;
}
static void add_part(struct cxl_dpa_info *info, u64 start, u64 size, enum cxl_partition_mode mode)
{
int i = info->nr_partitions;
if (size == 0)
return;
info->part[i].range = (struct range) {
.start = start,
.end = start + size - 1,
};
info->part[i].mode = mode;
info->nr_partitions++;
}
Annotation
- Immediate include surface: `linux/security.h`, `linux/debugfs.h`, `linux/ktime.h`, `linux/mutex.h`, `linux/unaligned.h`, `cxlpci.h`, `cxlmem.h`, `cxl.h`.
- Detected declarations: `struct cxl_get_security_output`, `function cxl_is_security_command`, `function cxl_set_security_cmd_enabled`, `function cxl_is_poison_command`, `function cxl_set_poison_cmd_enabled`, `function cxl_internal_send_cmd`, `function cxl_mem_raw_command_allowed`, `function cxl_payload_from_user_allowed`, `function cxl_mbox_cmd_ctor`, `function cxl_mbox_cmd_dtor`.
- Atlas domain: Driver Families / drivers/cxl.
- Implementation status: integration implementation candidate.
- This snippet crosses the user/kernel memory boundary; validate fault handling and access checks before translating the pattern.
- 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.