Re: [PATCH v1 1/9] scsi: scsi_debug: move ASC and ASCQ definitions to scsi_proto.h
Damien Le Moal <[email protected]> Mon, 6 Jul 2026 18:00:45 +0900
| Newsgroups | org.kernel.vger.linux-ide,org.kernel.vger.linux-scsi |
|---|---|
| Organization | Western Digital Research |
| Message-ID | <[email protected]> |
On 7/6/26 5:44 PM, Hannes Reinecke wrote: > Weelll ... _technically_ the ASC/ASCQ codes have to be evaluated > together, and the individual definitions only make sense for a > combination of ASC/ASCQ codes. Yes, I am well aware. > EG SPC-5 defines the ASC/ASCQ 0x20/0x00 as 'Invalid command opcode', > but with this we would deocde it as 'INVALID_OPCODE'/'POWER_ON_RESET_ASCQ', > but 'POWER ON RESET OCCURRED' is ASC/ASCQ 0x29/0x00. > So if we were to define ASCQ codes we would need to define the > ASCQ codes for each ASC to avoid these issues. Yes, this is messy. But re-check the specs. There are plenty of places that say "with additional sense code XXX" without actually specifying the exact combination of ASC/ASCQ as they are defined on the T10 site (https://www.t10.org/lists/asc-num.htm). > Makes me wonder if we shouldn't introduce u16 for sense code > handling ... Maybe, but that will be more work as we have many functions and code that handle asc and ascq separatly. Which I kind of like. The main benefit of having the macros and using them is code readability: the values used/tested for ASC & ASCQ become self explanatory, making it far easier to match code and specs. -- Damien Le Moal Western Digital Research