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