ufshcd_issue...man_upiu_cmd(9)

📦 version 7.3.1, in nixpkgs unstable

💅 ufshcd_issue_devman_upiu_cmd — NAME

okay so bestie, we're in the Kernel API Manual today, and the star of the show is:

ufshcd_issue_devman_upiu_cmd — the API for sending "utrd" type requests ✨

📜 SYNOPSIS

int ufshcd_issue_devman_upiu_cmd (struct ufs_hba *hba , struct utp_upiu_req *req_upiu , struct utp_upiu_req *rsp_upiu , u8 *desc_buff , int *buff_len , enum dev_cmd_type cmd_type , enum query_opcode desc_op );

🎀 ARGUMENTS

  • hba — per-adapter instance. your main character, fr.
  • req_upiu — upiu request. the ask 💌
  • rsp_upiu — upiu reply. the text back 🫶
  • desc_buff — pointer to descriptor buffer, NULL if NA
  • buff_len — descriptor size, 0 if NA
  • cmd_type — specifies the type (NOP, Query...)
  • desc_op — descriptor operation

💖 DESCRIPTION

So these types of requests use the UTP Transfer Request Descriptor — utrd, iykyk. Which means it literally "rides" the device management infrastructure: it uses its tag and its tasks work queues. not me being a lil passenger princess on the devman infra 😭👑

And here's the part where you gotta pay attention bestie — since there is only one available tag for device management commands, the caller is expected to hold the hba->dev_cmd.lock mutex. 🔒

⚠️ fr fr: only one tag exists for device management commands, so the caller is expected to hold the hba->dev_cmd.lock mutex. don't skip this, it's giving race condition energy and not in a cute way 💀

⭐ RETURN

0 upon success; < 0 upon failure. slay or flop, no in-between 💅

🌈 SEE ALSO

Kernel file ./drivers/ufs/core/ufshcd.c — and honestly the whole extended ufshcd family reunion:

k that's the whole page bestie, go hold that mutex and be iconic 🫶💜

sign-off szn: this one lives under ./drivers/ufs/core, dated October 2026 — same page name, ufshcd_issue...man_upiu_cmd(9), mwah 💋

📦 where this page comes from