SSAM_DEFINE...REQUEST_MD_R(9)

💅 SSAM_DEFINE_SYNC_REQUEST_MD_R — a.k.a. the "make me a multi-device SAM request function that gives stuff back" macro 💅

okay so bestie, welcome to section 9 of the Kernel API Manual — yes this is kernel-internals territory, but honestly? you're gonna slay. this page is literally about a macro that writes a whole function for you, no cap. 🫶

---

✨ SYNOPSIS ✨

SSAM_DEFINE_SYNC_REQUEST_MD_R (name , rtype , spec... );

like, that's it. that's the whole call. iconic. 🎀

---

🌸 ARGUMENTS 🌸

• name — what you're naming the generated function. your baby, your choice of name. 💖
• rtype — the type of the request's return value. so like, what flavour of data comes back out. 🍓
• spec — the specification (struct ssam_request_spec_md) that defines the request. this is the blueprint, the whole vibe check of what the request actually is. ✨

---

🦋 DESCRIPTION 🦋

so here's the tea: this macro defines a function that executes the synchronous SAM request specified by spec. the request takes no argument but it does have a return value of type rtype. 🎀

the device-specifying parameters? not hard-coded, bestie — nope. they have to be handed to the function when you call it. so the generated function is out here taking care of everything: setting up the request and response structs, buffer allocation, and the execution of the request itself — and it returns once the request has been fully completed. the way that it just handles all of that for you? obsessed. 😭🔥

also important: the required transport buffer gets allocated on the stack. 🫶

the generated function is defined exactly like this:

static int name(struct ssam_controller *ctrl, u8 tid, u8 iid, rtype *ret)

and it returns the status of the request, which is zero on success and negative on failure. 💀

breaking down the params, because iykyk:

• the ctrl parameter is the controller via which the request is sent 🌈
• tid is the target ID for the request 🎯
• iid is the instance ID 🔖
• the request's return value gets written to the memory pointed to by the ret parameter 💾

ngl, if you want the full behaviour of the generated function, go read ssam_request_do_sync_onstack — that's the real one to stan for details. 👑

---

👑 SEE ALSO 👑

• Kernel file ./include/linux/surface_aggregator/controller.h 📁
• enum ssam_event_flags(9)
• struct ssam_event(9)
• enum ssam_request_flags(9)
• struct ssam_request(9)
• struct ssam_response(9)
• struct ssam_request_sync(9)
• ssam_request_sync_set_data(9)
• ssam_request_sync_set_resp(9)
• ssam_request_sync_wait(9)
• ssam_request_do_sync_onstack(9)
• __ssam_retry(9)
• ssam_retry(9)
• struct ssam_request_spec(9)
• struct ssam_request_spec_md(9)
• SSAM_DEFINE_SYNC_REQUEST_N(9)
• SSAM_DEFINE_SYNC_REQUEST_W(9)
• SSAM_DEFINE_SYNC_REQUEST_R(9)
• SSAM_DEFINE_SYNC_REQUEST_WR(9)
• SSAM_DEFINE_SYNC_REQUEST_MD_N(9)
• SSAM_DEFINE_SYNC_REQUEST_MD_W(9)
• SSAM_DEFINE_SYNC_REQUEST_MD_WR(9)
• enum ssam_notif_flags(9)
• struct ssam_notifier_block(9)
• ssam_notifier_from_errno(9)
• ssam_notifier_to_errno(9)
• struct ssam_event_registry(9)
• struct ssam_event_id(9)
• enum ssam_event_mask(9)
• SSAM_EVENT_REGISTRY(9)
• enum ssam_event_notifier_flags(9)
• struct ssam_event_notifier(9)
• ssam_notifier_unregister(9)

like, that's a whole friend group right there. go say hi. 🌸💜

---

and that's the page, babe ✨ coming at you straight from the Kernel API Manual, section 9, sourced from ./include/linux/surface_aggreg... and dated October 2026 — periodt. 💅🎀🦋