hsi_async(9)

hsi_async(9) 💅

okay bestie, this is from the Kernel API Manual and we're talking about hsi_async — submit an HSI transfer to the controller. like, that's the whole page. let's go 🦋

🌸 NAME 🌸

hsi_async — submit an HSI transfer to the controller ✨

✨ SYNOPSIS ✨

int hsi_async (struct hsi_client *cl , struct hsi_msg *msg );

👑 ARGUMENTS 👑

• cl — the HSI client that is sending the transfer, main character energy 💅
• msg — the HSI transfer passed to the controller, aka the message getting submitted 🎀

💖 DESCRIPTION 💖

okay so your HSI message must have the channel, ttype, complete, and destructor fields set beforehand. no cap, set them before you call this.

if nents > 0, then the client also has to initialize the scatterlists so they point to the buffers to write to or read from. yes, that part is on you 🫶

HSI controllers relay on pre-allocated buffers from their clients, and they do not allocate buffers on their own. like, the buffers are the client's job, periodt.

once the HSI message transfer finishes, the HSI controller calls the complete callback with the status and actual_len fields of the HSI message updated. heads up: the complete callback can be called before returning from hsi_async — yes, before. so don't be shocked 😭

returns -errno on failure or 0 on success. that's the vibe check, bestie.

🔥 SEE ALSO 🔥

Kernel file: ./drivers/hsi/hsi_core.c — go peek if you're nosy 👀

• hsi_port_unregister_clients(9)
• hsi_unregister_controller(9)
• hsi_register_controller(9)
• hsi_register_client_driver(9)
• hsi_put_controller(9)
• hsi_alloc_controller(9)
• hsi_free_msg(9)
• hsi_alloc_msg(9)
• hsi_claim_port(9)
• hsi_release_port(9)
• hsi_register_port_event(9)
• hsi_unregister_port_event(9)
• hsi_event(9)
• hsi_get_channel_id_by_name(9)

source/version: ./drivers/hsi · date: October 2026 · page: hsi_async(9) — byeee, ily 🫶💖