mptscsih_get...pletion_code(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– mptscsih_get_completion_code(9) πŸ’–

okay so bestie, welcome to the Kernel API Manual!! this one's a tiny lil page but it's lowkey important β€” it's all about mptscsih_get_completion_code. and yes the header up top does that whole mptscsih_get...pletion_code(9) abbreviation thing, that's just the header being dramatic and saving space, the real name is the full one πŸŽ€


✨ NAME ✨

mptscsih_get_completion_code β€” get completion code from MPT request πŸ’…

like, you hand it an MPT request and it fishes out the completion code for you. that's the whole vibe. no cap.


πŸ¦‹ SYNOPSIS πŸ¦‹

int mptscsih_get_completion_code (MPT_ADAPTER *ioc , MPT_FRAME_HDR *req
, MPT_FRAME_HDR *reply );

it returns an int, slay πŸ’œ


🌸 ARGUMENTS 🌸

  • ioc β€” Pointer to MPT_ADAPTER structure. this is your adapter bestie, the main character of the whole operation πŸ‘‘
  • req β€” Pointer to original MPT request frame. the request as it was originally sent, fr fr 🫢
  • reply β€” Pointer to MPT reply frame (NULL if TurboReply). yes queen, NULL is a totally valid value here when it's a TurboReply β€” that's not a bug, that's the spec 😭

πŸ”₯ SEE ALSO πŸ”₯

bestie there is so much family here, it's giving found family energy 🌈 the kernel file ./drivers/message/fusion/mptscsih.c is the home base, and then we got:

go read them all, iykyk πŸ“šβœ¨


ok that's literally the whole page, it's a short one but she ate πŸ’… remember: pass a real ioc and req, and reply can be NULL for TurboReply. no guessing beyond that, that's what the page says πŸŽ€

sign-off time 🫢 this lil beauty lives under ./drivers/message/fusion and it's dated October 2026 β€” stay iconic, kernel besties, mwah πŸ’–βœ¨πŸ§š

πŸ“¦ where this page comes from