scmi_xfer_raw_worker(9)

💅 scmi_xfer_raw_worker(9) — like, the Kernel API Manual page, bestie ✨

okay so this is a page straight out of the Kernel API Manual (scmi_xfer_raw_worker(9), section 9, we love a manpage moment 🎀) and it's all about the work function that waits around for Raw xfer completions. yes. that's the whole vibe. let's get into it 🦋

---

✨ NAME ✨

scmi_xfer_raw_worker — the work function whose entire job is to wait for Raw xfers to finish, no cap 🫶

---

🌸 SYNOPSIS 🌸

void scmi_xfer_raw_worker (struct work_struct *work );

like, that's it. that's the signature. she's simple, she's iconic 👑

---

🎀 ARGUMENTS 🎀

• work — a reference to the work. yes, literally just "a reference to the work". she said what she said 💅

---

🔥 DESCRIPTION 🔥

so here's the situation, bestie. In SCMI Raw mode, once a user-provided injected SCMI message gets sent, we cannot just sit there waiting to receive its response (if any) inside the context of the injection routines 😭 because if we did, we'd leave the userspace write syscall — the one that delivered the SCMI message to send — just hanging, pending, until eventually a reply shows up. and that's giving main character energy in the worst way 💀

instead, userspace should and will poll/wait on the read syscalls, which are the ones in charge of reading a received reply (if any). so like, that part's handled. slay 🌈

now — even though reply messages are collected and reported into the SCMI Raw layer on the RX path, we nonetheless still have to properly wait for their completion as usual (and async_completion too, if needed) in order to properly release the xfer structure at the end ✨ to do that out of the context of the write/send, these waiting jobs get delegated to this deferred worker. very demure. very mindful. 🧚

any sent xfer that needs to be waited for is timestamped and queued for later consumption by this worker 💖 queue aging is accounted for while choosing a timeout for the completion, BUT — and this is important — we do not really care here if we end up accidentally waiting for a bit too long 🙈 like, it's fine. it's chill. go off queen.

ngl this whole thing is basically "don't block the write syscall, hand the waiting off to the worker, and if the timeout's a lil long, who cares 💅"

---

🦋 SEE ALSO 🦋

Kernel file ./drivers/firmware/arm_scmi/raw_mode.c — go read it, iykyk 👀

• Theory of operation(9)
• struct scmi_raw_queue(9)
• struct scmi_raw_mode_info(9)
• struct scmi_xfer_raw_waiter(9)
• struct scmi_raw_buffer(9)
• struct scmi_dbg_raw_data(9)
• scmi_xfer_raw_get_init(9)
• scmi_do_xfer_raw_start(9)
• scmi_raw_message_send(9)
• scmi_raw_message_receive(9)
• scmi_raw_mode_init(9)
• scmi_raw_mode_cleanup(9)
• scmi_raw_message_report(9)
• scmi_raw_error_report(9)

---

⭐ and that's the page!! from ./drivers/firmware/arm_scmi, dated October 2026, filed under scmi_xfer_raw_worker(9) — mwah, go touch some kernel code bestie 💜🎀🌸