On Fri, Jul 26, 2013 at 7:15 PM, Seungwon Jeon <tgih.jun@xxxxxxxxxxx> wrote:
> Fatal error in OCS(overall command status) field indicates
> error conditions which is not covered by UFSHCI.
> It means that host cannot define the result of command status
> and therefore host may need to check transfer response UPIU's
> response and status field.
> It was actually found that 'CHECK CONDITION' is stored in status
> field of UPIU where OCS is 'FATAL ERROR'.
It seems specific to the host controller you are checking with.
It doesn't seem right to interpret the scsi status -- even though the
handling isn't mentioned in the spec for FATAL ERROR.
>
> Signed-off-by: Seungwon Jeon <tgih.jun@xxxxxxxxxxx>
> ---
> drivers/scsi/ufs/ufshcd.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index b743bd6..4cf3a2d 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1199,7 +1199,7 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
>
> switch (ocs) {
> case OCS_SUCCESS:
> -
> + case OCS_FATAL_ERROR:
> /* check if the returned transfer response is valid */
> result = ufshcd_is_valid_req_rsp(lrbp->ucd_rsp_ptr);
> if (result) {
> @@ -1229,7 +1229,6 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
> case OCS_MISMATCH_DATA_BUF_SIZE:
> case OCS_MISMATCH_RESP_UPIU_SIZE:
> case OCS_PEER_COMM_FAILURE:
> - case OCS_FATAL_ERROR:
> default:
> result |= DID_ERROR << 16;
> dev_err(hba->dev,
> --
> 1.7.0.4
>
>
--
~Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
