UFSHCI defines OCS values but doesn't specify what exact
conditions raise them. So I think it needs another callback
to replace the original OCS value with the value that works
the way you want.

v1 -> v2: fix build error for arguments

Kiwoong Kim (2):
  scsi: ufs: core: introduce override_cqe_ocs
  scsi: ufs: ufs-exynos: implement override_cqe_ocs

 drivers/ufs/core/ufshcd-priv.h |  9 +++++++++
 drivers/ufs/core/ufshcd.c      | 11 +++++++----
 drivers/ufs/host/ufs-exynos.c  |  8 ++++++++
 include/ufs/ufshcd.h           |  1 +
 4 files changed, 25 insertions(+), 4 deletions(-)

-- 
2.7.4

On Thu, 2024-08-22 at 20:15 +0900, Kiwoong Kim wrote:
> Kiwoong Kim (2):
>   scsi: ufs: core: introduce override_cqe_ocs
>   scsi: ufs: ufs-exynos: implement override_cqe_ocs


Hi Kiwoong Kim,

I didn't see your patch email,just post your second patch here, and
provide my comments:

 
+static enum utp_ocs exynos_ufs_override_cqe_ocs(enum utp_ocs ocs)
+{
+	if (ocs == OCS_ABORTED)
+		ocs = OCS_INVALID_COMMAND_STATUS;
+	return ocs;
+}


I wonder if you have considered the case where the command is aborted
by the host software or by the device itself?

If you change OCS to OCS_INVALID_COMMAND_STATUS, there will report a
DID_REQUEUE to SCSI.


Kind regards,
Bean

> +static enum utp_ocs exynos_ufs_override_cqe_ocs(enum utp_ocs ocs) {
> +	if (ocs == OCS_ABORTED)
> +		ocs = OCS_INVALID_COMMAND_STATUS;
> +	return ocs;
> +}
> 
> 
> I wonder if you have considered the case where the command is aborted
> by the host software or by the device itself?

I mean by the host software and Exynos host reports OCS_ABORTED only for the case when MCQ is enabled.

> 
> If you change OCS to OCS_INVALID_COMMAND_STATUS, there will report a
> DID_REQUEUE to SCSI.

Yes. That's what I meant, in order to process them properly after UFS initialization.

> 
> 
> Kind regards,
> Bean

Thank you.

On 8/22/24 8:42 AM, Bean Huo wrote:
> On Thu, 2024-08-22 at 20:15 +0900, Kiwoong Kim wrote:
>> Kiwoong Kim (2):
>>    scsi: ufs: core: introduce override_cqe_ocs
>>    scsi: ufs: ufs-exynos: implement override_cqe_ocs
> 
> 
> Hi Kiwoong Kim,
> 
> I didn't see your patch email,just post your second patch here, and
> provide my comments:
> 
>   
> +static enum utp_ocs exynos_ufs_override_cqe_ocs(enum utp_ocs ocs)
> +{
> +	if (ocs == OCS_ABORTED)
> +		ocs = OCS_INVALID_COMMAND_STATUS;
> +	return ocs;
> +}
> 
> 
> I wonder if you have considered the case where the command is aborted
> by the host software or by the device itself?
> 
> If you change OCS to OCS_INVALID_COMMAND_STATUS, there will report a
> DID_REQUEUE to SCSI.

The decision about what to do probably should depend on whether or not
the command has been nullified.

Thanks,

Bart.

> > I wonder if you have considered the case where the command is aborted
> > by the host software or by the device itself?
> >
> > If you change OCS to OCS_INVALID_COMMAND_STATUS, there will report a
> > DID_REQUEUE to SCSI.
> 
> The decision about what to do probably should depend on whether or not
> the command has been nullified.
> 
> Thanks,
> 
> Bart.

When MCQ is enabled, Exynos host reports OCS_ABORTED only for nullified cases.

Thanks.

On Thu, 2024-08-22 at 20:15 +0900, Kiwoong Kim wrote:
> UFSHCI defines OCS values but doesn't specify what exact
> conditions raise them. So I think it needs another callback
> to replace the original OCS value with the value that works
> the way you want.
> 
> v1 -> v2: fix build error for arguments
> 
> Kiwoong Kim (2):
>   scsi: ufs: core: introduce override_cqe_ocs
>   scsi: ufs: ufs-exynos: implement override_cqe_ocs

Hi kiwoong Kim,

I didn't see your above two patches following your cover-letter, did
you send patch with "--thread" optioin?


Kind regards,
Bean

> 
>  drivers/ufs/core/ufshcd-priv.h |  9 +++++++++
>  drivers/ufs/core/ufshcd.c      | 11 +++++++----
>  drivers/ufs/host/ufs-exynos.c  |  8 ++++++++
>  include/ufs/ufshcd.h           |  1 +
>  4 files changed, 25 insertions(+), 4 deletions(-)
> 

On 8/22/24 7:54 AM, Bean Huo wrote:
> I didn't see your above two patches following your cover-letter, did
> you send patch with "--thread" optioin?

I haven't received these patches either but found them here:

https://lore.kernel.org/linux-scsi/763ab716ba0207ecdad6f55ce38edf2d1bc7d04b.1724325280.git.kwmad.kim@samsung.com/

Bart.

> https://lore.kernel.org/linux-
> scsi/763ab716ba0207ecdad6f55ce38edf2d1bc7d04b.1724325280.git.kwmad.kim@sam
> sung.com/
> 
> Bart.

I included you but sending the patch set was blocked.
Sorry. Let me fix this as soon as possible.

Thank you.