Re: [PATCH 1/2] ata: libata-scsi: Fix system suspend for a security locked drive

[Damien Le Moal <dlemoal@kernel.org>]

On 11/19/25 11:13 PM, Niklas Cassel wrote:
> Commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status
> handling") fixed ata_to_sense_error() to properly generate sense key
> ABORTED COMMAND (without any additional sense code), instead of the
> previous bogus sense key ILLEGAL REQUEST with the additional sense code
> UNALIGNED WRITE COMMAND, for a failed command.
> 
> However, this broke suspend for Security locked drives (drives that have
> Security enabled, and have not been Security unlocked by boot firmware).
> 
> The reason for this is that the SCSI disk driver, for the Synchronize
> Cache command only, treats any sense data with sense key ILLEGAL REQUEST
> as a successful command (regardless of ASC / ASCQ).
> 
> After commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error()
> status handling") the code that treats any sense data with sense key
> ILLEGAL REQUEST as a successful command is no longer applicable, so the
> command fails, which causes the system suspend to be aborted:
> 
>   sd 1:0:0:0: PM: dpm_run_callback(): scsi_bus_suspend returns -5
>   sd 1:0:0:0: PM: failed to suspend async: error -5
>   PM: Some devices failed to suspend, or early wake event detected
> 
> To make suspend work once again, for a Security locked device only,
> return sense data LOGICAL UNIT ACCESS NOT AUTHORIZED, the actual sense
> data which a real SCSI device would have returned if locked.
> The SCSI disk driver treats this sense data as a successful command.
> 
> Cc: stable@vger.kernel.org
> Reported-by: Ilia Baryshnikov <qwelias@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220704
> Fixes: cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling")
> Signed-off-by: Niklas Cassel <cassel@kernel.org>

I think that adding this to ata_scsi_flush_xlat() would be better, but this way
may be able to catch more cases like sync failure. So for now, let's go with this.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>


-- 
Damien Le Moal
Western Digital Research