STRUCT TI_SCI_MSG_RESP_GET_DEVICE_STATE(9)
π¦ struct ti_sci_msg_resp_get_device_state(9) β Kernel API Manual π¦
okay so bestie, we're in the Kernel API Manual today and this page is literally all about one struct: struct ti_sci_msg_resp_get_device_state. it's giving "reply text from the firmware" energy and tbh it's kind of iconic π
β¨ NAME β¨
struct ti_sci_msg_resp_get_device_state β the response message you get back for a get-device request, no cap π«Ά
πΈ SYNOPSIS πΈ
struct ti_sci_msg_resp_get_device_state {
struct ti_sci_msg_hdr hdr;
u32 context_loss_count;
u32 resets;
u8 programmed_state;
#define MSG_DEVICE_HW_STATE_OFF 0;
#define MSG_DEVICE_HW_STATE_ON 1;
#define MSG_DEVICE_HW_STATE_TRANS 2;
u8 current_state;
};
π Members π
π the fields, one by one
hdrβ the generic header. yes bestie, every message gets one, it's the main character of the struct β¨context_loss_countβ tells you how many times the device has lost context. a driver can use this monotonic counter to figure out whether the device lost context since the last time this message was exchanged π (monotonic = it only goes up, it never lies to you)resetsβ the programmed state of the reset lines π«Άprogrammed_stateβ the state as programmed byset_device. so like, what somebody asked for- π« uses the
MSG_DEVICE_SW_*macros
- π« uses the
current_stateβ the actual state of the hardware. so like, what's actually happening in there π (and yes it can differ from programmed_state, that's the whole vibe check)
π₯ Description π₯
literally just: it's the response to the request TI_SCI_MSG_GET_DEVICE_STATE. that's the whole plot π
π SEE ALSO π
all the siblings, and there are so many, ok slay π β from the kernel file ./drivers/firmware/ti_sci.h:
struct ti_sci_msg_hdr(9)struct ti_sci_msg_resp_version(9)struct ti_sci_msg_req_reboot(9)struct ti_sci_msg_resp_query_fw_caps(9)struct ti_sci_msg_req_set_device_state(9)struct ti_sci_msg_req_get_device_state(9)struct ti_sci_msg_req_set_device_resets(9)struct ti_sci_msg_req_set_clock_state(9)struct ti_sci_msg_req_get_clock_state(9)struct ti_sci_msg_resp_get_clock_state(9)struct ti_sci_msg_req_set_clock_parent(9)struct ti_sci_msg_req_get_clock_parent(9)struct ti_sci_msg_resp_get_clock_parent(9)struct ti_sci_msg_req_get_clock_num_parents(9)struct ti_sci_msg_resp_get_clock_num_parents(9)struct ti_sci_msg_req_query_clock_freq(9)struct ti_sci_msg_resp_query_clock_freq(9)struct ti_sci_msg_req_set_clock_freq(9)struct ti_sci_msg_req_get_clock_freq(9)struct ti_sci_msg_resp_get_clock_freq(9)struct ti_sci_msg_req_prepare_sleep(9)struct ti_sci_msg_req_set_io_isolation(9)struct ti_sci_msg_resp_lpm_wake_reason(9)struct ti_sci_msg_req_lpm_set_device_constraint(9)struct ti_sci_msg_req_lpm_set_latency_constraint(9)struct ti_sci_msg_req_get_resource_range(9)struct ti_sci_msg_resp_get_resource_range(9)struct ti_sci_msg_req_manage_irq(9)struct ti_sci_msg_rm_ring_cfg_req(9)struct ti_sci_msg_psil_pair(9)struct ti_sci_msg_psil_unpair(9)struct ti_sci_msg_udmap_rx_flow_cfg(9)struct rm_ti_sci_msg_udmap_rx_flow_opt_cfg(9)struct ti_sci_msg_rm_udmap_tx_ch_cfg_req(9)struct ti_sci_msg_rm_udmap_rx_ch_cfg_req(9)struct ti_sci_msg_rm_udmap_flow_cfg_req(9)struct ti_sci_msg_req_proc_request(9)struct ti_sci_msg_req_proc_release(9)struct ti_sci_msg_req_proc_handover(9)struct ti_sci_msg_req_set_config(9)struct ti_sci_msg_req_set_ctrl(9)struct ti_sci_msg_req_get_status(9)struct ti_sci_msg_resp_get_status(9)
go read them all, i'll wait π§π
π friendly reminder thatprogrammed_stateandcurrent_stateare two different things and mixing them up is not the move, bestie. also theMSG_DEVICE_HW_STATE_OFF/_ON/_TRANSdefines live right in the middle of the struct, which is lowkey chaotic but it's what we have π
and that's the page!! sourced from ./drivers/firmware, dated October 2026, and typed out with love by struct ti_s...device_state(9) β bye bestie, drink some water πβ¨πΈ
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms