rsu_get_devi...nfo_callback(9)

📦 version 7.3.1, in nixpkgs unstable

💅 rsu_get_device_info_callback(9) 💅

okay so bestie, we're in the Kernel API Manual today and this one is literally the little callback that could 🫶 it's the function that grabs the QSPI device info back from the Intel service layer, and yes it's a whole vibe. sit down, grab a strawberry 🍓, let's go.

✨ NAME ✨

rsu_get_device_info_callback — the callback from the Intel service layer that gets you the QSPI device info. no cap, that's the whole job 👑

🌸 SYNOPSIS 🌸

void rsu_get_device_info_callback (struct stratix10_svc_client *client ,
struct stratix10_svc_cb_data *data );

🎀 ARGUMENTS 🎀

  • client — pointer to client. just a lil pointer, living its life 💖
  • data — pointer to the callback data structure. this is the one that actually carries the tea ☕

🦋 DESCRIPTION 🦋

so this is a callback from the Intel service layer for QSPI device info — iconic behavior honestly ✨

here's the important bit, listen up: data->kaddr1 points to struct arm_smccc_1_2_regs on SVC_STATUS_OK or SVC_STATUS_ERROR. but on SVC_STATUS_NO_SUPPORT (that's the unsupported command case, iykyk) it's NULL. so like, check it, bestie, don't just assume 🫠

no cap: kaddr1 is NULL when the status is SVC_STATUS_NO_SUPPORT. that's not a maybe, that's a fact 💀

🔥 SEE ALSO 🔥

the kernel file in question, main character energy:

  • ./drivers/firmware/stratix10-rsu.c

and the whole friend group 🫶:

and that's the page, bestie 💜 it lives in ./drivers/firmware, dated October 2026, and it's filed under rsu_get_devi...nfo_callback(9) — go forth and slay your device info retrieval 🌈👑✨

📦 where this page comes from