On 10/5/22 09:18, Mike Christie wrote:
On 10/4/22 5:27 PM, Bart Van Assche wrote:
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index bac55decf900..9ab97e48c5c2 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -65,6 +65,24 @@ enum scsi_cmnd_submitter {
SUBMITTED_BY_SCSI_RESET_IOCTL = 2,
} __packed;
+#define SCMD_FAILURE_NONE 0
+#define SCMD_FAILURE_ANY -1
This is the same value as -EPERM. Would something like 0x7fffffff be a better
choice for SCMD_FAILURE_ANY?
I didn't get that. All of this is used for the scsi_cmnd->result evaluation
and retries (host, status, internal bytes) which are all positive and where
we don't use -Exyx errors.
(just noticed that I had not yet replied to this email and that this
conversation is also relevant for v4 of this patch series).
Last time I checked I found a few SCSI LLDs that assign -Exyz error
values to the scsi_cmnd->result field, e.g. the scsi_debug driver.
However, I'm not sure that is still the case today.
+struct scsi_failure {
+ int result;
+ u8 sense;
+ u8 asc;
+ u8 ascq;
+
+ s8 allowed;
+ s8 retries;
+};
Why has 'retries' type s8 instead of u8?
There is a:
#define SCMD_FAILURE_NO_LIMIT -1
in the defines that got cut off when you replied which is used for some
users that had no limit on retries.
Hmm ... isn't SCMD_FAILURE_NO_LIMIT a value that only should be assigned
to the .allowed member and not to the .retries member? Is my
understanding correct that the .retries member should be set to zero
before execution of a SCSI command start and that the only manipulation
that happens on that member is incrementing it in scsi_check_passthrough()?
Thanks,
Bart.
