block/sed-opal.c
Source file repositories/reference/linux-study-clean/block/sed-opal.c
File Facts
- System
- Linux kernel
- Corpus path
block/sed-opal.c- Extension
.c- Size
- 90752 bytes
- Lines
- 3728
- Domain
- Representative Device Path
- Bucket
- PCIe NVMe Storage Path
- Inferred role
- Representative Device Path: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Part of the selected hardware vertical slice: PCI discovery, driver binding, NVMe queues, block requests, DMA, interrupts, and completion.
- Part of the selected hardware vertical slice: PCI discovery, driver binding, NVMe queues, block requests, DMA, interrupts, and completion.
- 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.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- 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/delay.hlinux/device.hlinux/kernel.hlinux/list.hlinux/blkdev.hlinux/slab.hlinux/uaccess.huapi/linux/sed-opal.hlinux/sed-opal.hlinux/sed-opal-key.hlinux/string.hlinux/kdev_t.hlinux/key.hlinux/key-type.hkeys/user-type.hopal_proto.h
Detected Declarations
struct opal_stepstruct opal_resp_tokstruct parsed_respstruct opal_devstruct opal_suspend_dataenum opal_atom_widthfunction print_bufferfunction update_sed_opal_keyfunction read_sed_opal_keyfunction opal_get_keyfunction check_tperfunction check_lcksupptfunction check_lckenabledfunction check_lockedfunction check_mbrenabledfunction check_mbrdonefunction check_sumfunction get_comid_v100function get_comid_v200function opal_send_cmdfunction opal_recv_cmdfunction opal_recv_checkfunction opal_send_recvfunction check_geometryfunction execute_stepfunction execute_stepsfunction opal_discovery0_endfunction opal_discovery0function opal_discovery0_stepfunction remaining_sizefunction can_addfunction add_token_u8function add_short_atom_headerfunction add_medium_atom_headerfunction add_token_u64function add_token_bytestringfunction build_locking_rangefunction build_locking_userfunction set_comidfunction cmd_finalizefunction response_parse_tinyfunction response_parse_shortfunction response_parse_mediumfunction response_parse_longfunction response_parse_tokenfunction response_parsefunction response_get_stringfunction response_get_u64
Annotated Snippet
struct opal_step {
int (*fn)(struct opal_dev *dev, void *data);
void *data;
};
typedef int (cont_fn)(struct opal_dev *dev);
enum opal_atom_width {
OPAL_WIDTH_TINY,
OPAL_WIDTH_SHORT,
OPAL_WIDTH_MEDIUM,
OPAL_WIDTH_LONG,
OPAL_WIDTH_TOKEN
};
/*
* On the parsed response, we don't store again the toks that are already
* stored in the response buffer. Instead, for each token, we just store a
* pointer to the position in the buffer where the token starts, and the size
* of the token in bytes.
*/
struct opal_resp_tok {
const u8 *pos;
size_t len;
enum opal_response_token type;
enum opal_atom_width width;
union {
u64 u;
s64 s;
} stored;
};
/*
* From the response header it's not possible to know how many tokens there are
* on the payload. So we hardcode that the maximum will be MAX_TOKS, and later
* if we start dealing with messages that have more than that, we can increase
* this number. This is done to avoid having to make two passes through the
* response, the first one counting how many tokens we have and the second one
* actually storing the positions.
*/
struct parsed_resp {
int num;
struct opal_resp_tok toks[MAX_TOKS];
};
struct opal_dev {
u32 flags;
void *data;
sec_send_recv *send_recv;
struct mutex dev_lock;
u16 comid;
u32 hsn;
u32 tsn;
u64 align; /* alignment granularity */
u64 lowest_lba;
u32 logical_block_size;
u8 align_required; /* ALIGN: 0 or 1 */
size_t pos;
u8 *cmd;
u8 *resp;
struct parsed_resp parsed;
size_t prev_d_len;
void *prev_data;
struct list_head unlk_lst;
};
static const u8 opaluid[][OPAL_UID_LENGTH] = {
/* users */
[OPAL_SMUID_UID] =
{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff },
[OPAL_THISSP_UID] =
{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 },
[OPAL_ADMINSP_UID] =
{ 0x00, 0x00, 0x02, 0x05, 0x00, 0x00, 0x00, 0x01 },
[OPAL_LOCKINGSP_UID] =
{ 0x00, 0x00, 0x02, 0x05, 0x00, 0x00, 0x00, 0x02 },
[OPAL_ENTERPRISE_LOCKINGSP_UID] =
{ 0x00, 0x00, 0x02, 0x05, 0x00, 0x01, 0x00, 0x01 },
[OPAL_ANYBODY_UID] =
{ 0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x00, 0x01 },
[OPAL_SID_UID] =
{ 0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x00, 0x06 },
[OPAL_ADMIN1_UID] =
{ 0x00, 0x00, 0x00, 0x09, 0x00, 0x01, 0x00, 0x01 },
[OPAL_USER1_UID] =
Annotation
- Immediate include surface: `linux/delay.h`, `linux/device.h`, `linux/kernel.h`, `linux/list.h`, `linux/blkdev.h`, `linux/slab.h`, `linux/uaccess.h`, `uapi/linux/sed-opal.h`.
- Detected declarations: `struct opal_step`, `struct opal_resp_tok`, `struct parsed_resp`, `struct opal_dev`, `struct opal_suspend_data`, `enum opal_atom_width`, `function print_buffer`, `function update_sed_opal_key`, `function read_sed_opal_key`, `function opal_get_key`.
- Atlas domain: Representative Device Path / PCIe NVMe Storage Path.
- 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.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
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.