SSAM_DEFINE...REQUEST_CL_R(9)

💅 SSAM_DEFINE...REQUEST_CL_R(9) — Kernel API Manual, but make it make sense

okay bestie, so this is a page from the Kernel API Manual and it's about one very specific macro. no cap, it's iconic once you get it. let's go 🫶

---

✨ NAME ✨

SSAM_DEFINE_SYNC_REQUEST_CL_R — it defines a synchronous client-device SAM request function with a return value. that's the whole vibe. ✨

---

🌸 SYNOPSIS 🌸

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

literally just three things and you're done 💅

---

🎀 ARGUMENTS 🎀

• name — the name of the generated function. you pick it, you own it 👑
• rtype — the type of the request's return value. this is the what comes back type.
• spec — the specification (that's a struct ssam_request_spec_md) that defines the request. the blueprint, the moment, the blueprint-moment 🦋

---

💖 DESCRIPTION 💖

so what this actually does: it defines a function that executes the synchronous SAM request specified by spec, and this request takes no argument but has a return value of type rtype. notice the energy — no argument, all return value. main character behavior fr fr.

the device-specifying parameters are not hard-coded, they're provided via the client device — specifically its UID — supplied when you call this function. so no, it's not out here guessing which device you meant 🙈

the generated function handles all the setup for you:

• setting up the request struct
• buffer allocation
• executing the request itself

and it returns once the request has been fully completed. not before. don't @ me. the required transport buffer will be allocated on the stack.

the generated function is defined as:

static int name(struct ssam_device *sdev, rtype *ret)

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

the sdev parameter specifies both the target device of the request and by association the controller via which the request is sent. two jobs, one parameter, we love a multitasker 🫶

the request's return value is written to the memory pointed to by the ret parameter. that's where the goods land 📦

also fr, go read ssam_request_do_sync_onstack for more details on the behavior of the generated function. it's giving "required reading" but like, in a cute way. 💜

---

🌈 SEE ALSO 🌈

Kernel file ./include/linux/surface_aggregator/device.h, plus all these icons:

• enum ssam_device_domain(9)
• enum ssam_virtual_tc(9)
• struct ssam_device_uid(9)
• SSAM_DEVICE(9)
• SSAM_VDEV(9)
• SSAM_SDEV(9)
• struct ssam_device(9)
• struct ssam_device_driver(9)
• is_ssam_device(9)
• to_ssam_device(9)
• to_ssam_device_driver(9)
• ssam_device_mark_hot_removed(9)
• ssam_device_is_hot_removed(9)
• ssam_device_get(9)
• ssam_device_put(9)
• ssam_device_get_drvdata(9)
• ssam_device_set_drvdata(9)
• ssam_device_driver_register(9)
• module_ssam_device_driver(9)
• ssam_register_clients(9)
• ssam_device_register_clients(9)
• SSAM_DEFINE_SYNC_REQUEST_CL_N(9)
• SSAM_DEFINE_SYNC_REQUEST_CL_W(9)
• SSAM_DEFINE_SYNC_REQUEST_CL_WR(9)
• ssam_device_notifier_register(9)
• ssam_device_notifier_unregister(9)

the N, W, and WR siblings are all right there — a whole family, we stan a supportive sibling set 👑

---

and that's the page, bestie — sourced from ./include/linux/surface_aggreg..., dated October 2026, no cap 🌸✨💅