OSDN Git Service

scsi: pm8001: Use sas_ata_device_link_abort() to handle NCQ errors
authorJohn Garry <john.garry@huawei.com>
Mon, 17 Oct 2022 09:20:33 +0000 (17:20 +0800)
committerMartin K. Petersen <martin.petersen@oracle.com>
Tue, 18 Oct 2022 02:37:45 +0000 (02:37 +0000)
commit811be570a9a8df96b4fd43ff00837b947bbaf49b
tree0d22aca7769ecca1f460265a32871a21d3bf71e7
parent0b639decf65160b1afd9993019be37d7869c0340
scsi: pm8001: Use sas_ata_device_link_abort() to handle NCQ errors

In commit c6b9ef5779c3 ("[SCSI] pm80xx: NCQ error handling changes") the
driver had support added to handle NCQ errors but much of what is done in
this handling is duplicated from the libata EH.

In that named commit we handle in 2x main steps:

 a. Issue read log ext10 to examine and clear the errors

 b. Issue SATA_ABORT all command

Indeed, in libata EH, we do similar to above:

 a. ata_do_eh() -> ata_eh_autopsy() -> ata_eh_link_autopsy() ->
    ata_eh_analyze_ncq_error() -> ata_eh_read_log_10h()

 b. ata_do_eh() -> ata_eh_recover() which will issue a device soft reset
    or hard reset

Since there is so much duplication, use sas_ata_device_link_abort() which
will abort all pending IOs and kick of ATA EH which will do the steps,
above.

However we will not follow the advisory to send the SATA_ABORT all command
after the autopsy in read log ext10. Indeed, in libsas EH, we already send
a per-task SATA_ABORT command, and this is prior to the ATA EH kicking in
and issuing the read log ext10 in the recovery process. I judge that this
is ok as the SATA_ABORT command does not actually send any protocol on the
link to abort I/O on the other side, so would not change any state on the
disk (for the read log ext10 command).

Signed-off-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1665998435-199946-7-git-send-email-john.garry@huawei.com
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Niklas Cassel <niklas.cassel@wdc.com> # pm80xx
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/pm8001/pm8001_hwi.c
drivers/scsi/pm8001/pm8001_sas.c
drivers/scsi/pm8001/pm8001_sas.h
drivers/scsi/pm8001/pm80xx_hwi.c