lpfc_nvmet_xmt_ls_rsp_cmp(9)

📦 version 7.3.1, in nixpkgs unstable

💅 lpfc_nvmet_xmt_ls_rsp_cmp(9) 💅

okay bestie, welcome to the Kernel API Manual, section 9 — today's main character is lpfc_nvmet_xmt_ls_rsp_cmp, and she is literally the completion handler for LS Response. no cap. let's get into it 🫶

✨ NAME ✨

lpfc_nvmet_xmt_ls_rsp_cmp — Completion handler for LS Response. that's it, that's the whole vibe check 🎀

🌸 SYNOPSIS 🌸

void lpfc_nvmet_xmt_ls_rsp_cmp (struct lpfc_hba *phba , struct
lpfc_iocbq *cmdwqe , struct lpfc_iocbq *rspwqe );

she returns void, so like… no receipts, no return value, just vibes and side effects 💀

🦋 ARGUMENTS 🦋

  • phba — Pointer to HBA context object. the whole HBA situation lives here, she's the context queen 👑
  • cmdwqe — Pointer to driver command WQE object. the command side of the story ✨
  • rspwqe — Pointer to driver response WQE object. and here's the response side, matching set, iconic 🎀

💖 DESCRIPTION 💖

so here's the tea: this function gets called from the SLI ring event handler with no lock held — like, zero locks, she's out here free and unbothered, no cap 🔥

she is the completion handler for NVME LS commands, and honestly she keeps it simple: first she updates any states and statistics (bookkeeping slay 💅), and then she calls the generic completion handler to free resources. cleanup era. we love a function that tidies up after herself 🧚

🌈 SEE ALSO 🌈

Kernel file ./drivers/scsi/lpfc/lpfc_nvmet.c — go read the source bestie, it's giving main character energy 📖

and the whole friend group, fr fr:

quick reminder bestie: she runs with no lock held — that's not a vibe, that's a fact, so don't go assuming any locking magic happens in here 🙈

and that's the whole page!! sourced from ./drivers/scsi/lpfc, dated October 2026, page lpfc_nvmet_xmt_ls_rsp_cmp(9) — mwah 💋 periodt 🦋✨

📦 where this page comes from