scsi_report_opcode(9)

📦 version 7.3.1, in nixpkgs unstable

🌸 scsi_report_opcode(9) 🌸

okay bestie, welcome to the Kernel API Manual — specifically the page for scsi_report_opcode(9). this one's short and sweet, so let's get into it 💅

✨ NAME ✨

scsi_report_opcode — find out if a given command is supported 🕵️‍♀️

🦋 SYNOPSIS 🦋

int scsi_report_opcode (struct scsi_device *sdev , unsigned char *buffer , unsigned int len , unsigned char opcode , unsigned short sa );

🎀 ARGUMENTS 🎀

  • sdev — the scsi device you're querying, like, the one you want the tea from 🫖
  • buffer — a scratch buffer. and she must be at least 20 bytes long, no exceptions bestie 😤
  • len — the length of buffer (yes, you have to tell it — it's not psychic)
  • opcode — the opcode of the command you're looking up 🔍
  • sa — the service action for the command you're looking up

💖 DESCRIPTION 💖

so the way this works is it uses REPORT SUPPORTED OPERATION CODES to check whether the command identified by opcode and sa is supported. iconic, love that for us.

quick note tho: if the command doesn't have a service action, then sa must be 0 — like, that's the rule, no cap 🙈

and here's the return vibe check:

  • returns -EINVAL if RSOC fails 💀
  • returns 0 if the command is not supported 😭
  • returns 1 if the device claims to support the command 👑 (claims!! we're taking its word for it, bestie)

🌈 SEE ALSO 🌈

kernel file ./drivers/scsi/scsi.c — and literally the whole friend group:

ngl, this whole page lives in ./drivers/scsi — that's her address, that's her home 🏡

and that's the whole page, bestie! sign-off time: this one's from ./drivers/scsi, dated October 2026, and it's scsi_report_opcode(9) through and through. slay, study it, periodt 💜✨

📦 where this page comes from