SSAM_DEFINE_...EQUEST_CL_WR(9)

💅 SSAM_DEFINE_SYNC_REQUEST_CL_WR — okay bestie, listen

This is a kernel API manual page for SSAM_DEFINE_SYNC_REQUEST_CL_WR(9), and honestly? It's giving macro magic. Let's get into it ✨

---

🌸 NAME 🌸

SSAM_DEFINE_SYNC_REQUEST_CL_WR — defines a synchronous client-device SAM request function that takes an argument and hands you back a return value. Both. At once. Iconic behavior fr fr.

---

🎀 SYNOPSIS 🎀

SSAM_DEFINE_SYNC_REQUEST_CL_WR (name , atype , rtype , spec... );

---

🦋 ARGUMENTS 🦋

• name — the name you're giving to the generated function. Your baby, your naming rights 💖
• atype — the type of the request's argument. What you're feeding in.
• rtype — the type of the request's return value. What you're getting back 🫶
• spec — the spec, aka a struct ssam_request_spec_md, that defines the request. This is the blueprint, the whole plan.

---

✨ DESCRIPTION ✨

So what this macro does is: it defines a function that executes the synchronous SAM request described by spec. The request takes an argument of type atype and has a return value of type rtype. Both, together, one function. Slay.

Here's the cute part — the device-specifying parameters are not hard-coded. Instead they're provided via the client device, specifically its UID, which you supply when you call the function. No cap, that's the whole vibe.

The generated function handles all the tedious stuff for you:

• setting up the request struct
• buffer allocation
• execution of the request itself

…and it returns once the request has been fully completed. And the required transport buffer? Allocated on the stack. Lowkey efficient 🧚

The generated function is defined exactly like this:

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

It returns the status of the request — zero on success, negative on failure. Bet.

Now let's break down those params, because they matter:

• sdev specifies both the target device of the request and, by association, the controller via which the request is sent. Two jobs, one pointer, main character energy 👑
• arg — the request's argument goes here, via the arg pointer.
• ret — the request's return value gets written to the memory pointed to by the ret parameter.

Wanna know more about how the generated function actually behaves? Go read ssam_request_do_sync_onstack. It's got the lore 📖

---

🌈 SEE ALSO 🌈

Kernel file ./include/linux/surface_aggregator/device.h, plus this whole friend group:

• 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_R(9)
• ssam_device_notifier_register(9)
• ssam_device_notifier_unregister(9)

---

That's the whole page, bestie — go forth and define your synchronous client-device SAM request functions 💅

This one's from the kernel file ./include/linux/surface_aggreg..., dated October 2026. Mwah, take care, iykyk 🍓