> On 4/15/19 5:23 AM, Stanley Chu wrote: > > If UFS device responds an unknown request response code, we can not > > know what it was via logs because the code is replaced by "DID_ERROR > > << 16" before log printing. > > > > Fix this to provide precise request response code information for > > easier issue breakdown. > > > > Signed-off-by: Stanley Chu <stanley....@mediatek.com> > > --- > > drivers/scsi/ufs/ufshcd.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > > index e040f9dd9ff3..fbe1e88eec55 100644 > > --- a/drivers/scsi/ufs/ufshcd.c > > +++ b/drivers/scsi/ufs/ufshcd.c > > @@ -4704,10 +4704,10 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, > struct ufshcd_lrb *lrbp) > > "Reject UPIU not fully implemented\n"); > > break; > > default: > > - result = DID_ERROR << 16; > > dev_err(hba->dev, > > "Unexpected request response code = %x\n", > > result); > > + result = DID_ERROR << 16; > > break; > > } > > break; > > > > Should "Fixes:" and "Cc: stable" tags be added to this patch?
Doesn't look like a regression or a critical issue. The patch looks good to me. Thanks Tomas
