do_xfer_with_response(9)

💅 do_xfer_with_response(9) — from the Kernel API Manual, bestie 🎀

okay so real talk, this one lives in do_xfer_with_response(9) land and it is exactly what it says on the tin. let me walk you through it 🫶

---

✨ NAME ✨

do_xfer_with_response — do one transfer and then literally just sit there and wait until the delayed response shows up. no cap, that's the whole job 💀

---

🌸 SYNOPSIS 🌸

int do_xfer_with_response (const struct scmi_protocol_handle *ph ,
                           struct scmi_xfer *xfer );

---

🦋 ARGUMENTS 🦋

• ph — pointer to the SCMI protocol handle. your VIP pass to the protocol, basically 👑
• xfer — the transfer you're kicking off and waiting on for a response. it's giving "start it and stay tuned" energy ✨

---

🧚 DESCRIPTION 🧚

okay bestie, listen up, this part is important 🔥

using asynchronous commands in atomic/polling mode? avoid, avoid, avoid. it could cause some seriously long busy-waiting right here, and nobody has time for that. so this function ignores polling for the delayed response, and it will WARN if polling was requested for this command transaction — because upper layers are supposed to refrain from issuing that kind of request in the first place 🙈

and before you ask "well what was the other option?" — here's the tea ☕ the only other option would have been to not use any asynchronous command at all, even if one was made available, whenever an atomic transport is detected, and instead forcibly use the synchronous version (which, ngl, is a thing that can be easily attained at the protocol layer). but that would also have led to longer stalls of the channel for synchronous commands and possibly timeouts 😭

in other words: there's usually a good reason when a platform provides an asynchronous version of a command, and we should prefer to use it… just not when using atomic/polling mode. periodt 💅

---

⭐ RETURN ⭐

• -ETIMEDOUT — bestie, no delayed response came 😔
• if it's a transmit error, you get the corresponding error back
• else, if everything goes well? 0 🎉 slay

---

💖 SEE ALSO 💖

the whole squad, gathered for you 🫶 first up, the kernel file itself:

• Kernel file ./drivers/firmware/arm_scmi/driver.c
• struct scmi_xfers_info(9)
• struct scmi_protocol_instance(9)
• struct scmi_info(9)
• scmi_create_protocol_devices(9)
• scmi_xfer_token_set(9)
• scmi_xfer_token_clear(9)
• scmi_xfer_inflight_register_unlocked(9)
• scmi_xfer_inflight_register(9)
• scmi_xfer_raw_inflight_register(9)
• scmi_xfer_pending_set(9)
• scmi_xfer_get(9)
• scmi_xfer_raw_get(9)
• scmi_xfer_raw_channel_get(9)
• __scmi_xfer_put(9)
• scmi_xfer_raw_put(9)
• scmi_xfer_lookup_unlocked(9)
• scmi_bad_message_trace(9)
• scmi_msg_response_validate(9)
• scmi_xfer_state_update(9)
• scmi_xfer_command_acquire(9)
• scmi_rx_callback(9)
• xfer_put(9)
• scmi_wait_for_message_response(9)
• scmi_xfer_raw_wait_for_message_response(9)
• do_xfer(9)
• xfer_get_init(9)
• version_get(9)
• scmi_set_protocol_priv(9)
• scmi_get_protocol_priv(9)
• scmi_common_extended_name_get(9)
• scmi_common_get_max_msg_size(9)
• scmi_protocol_msg_check(9)
• struct scmi_iterator(9)
• scmi_revision_area_get(9)
• scmi_protocol_version_negotiate(9)
• scmi_protocol_version_initialize(9)
• scmi_alloc_init_protocol_instance(9)
• scmi_get_protocol_instance(9)
• scmi_protocol_acquire(9)
• scmi_protocol_release(9)
• scmi_devm_protocol_get(9)
• scmi_devm_protocol_acquire(9)
• scmi_devm_protocol_put(9)
• scmi_is_transport_atomic(9)
• scmi_handle_get(9)
• scmi_handle_put(9)
• scmi_channels_setup(9)

---

and that's the whole page, bestie 🍓 mwah 💋

signing off from ./drivers/firmware/arm_scmi, dated October 2026 — catch you in the next manpage, ily, bye 🧚‍♀️💜