Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

2016-09-29 Thread Martin K. Petersen
> "Kiwoong" == Kiwoong Kim  writes:

Kiwoong> I think that the patch is correct.  UFS spec says "The Data
Kiwoong> Segment area is empty" for Read Descriptor.  I have been using
Kiwoong> similar code with it and it works.  That have been already
Kiwoong> applied in Android kernel.

That's fine. Just checking.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

2016-09-28 Thread subhashj

On 2016-09-27 22:14, Martin K. Petersen wrote:

"Subhash" == subhashj   writes:


Subhash> Looks good to me.


-   /* Data segment length */
-   ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD(
-   0, 0, len >> 8, (u8)len);
+   /* Data segment length only need for WRITE_DESC */
+   if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC)
+   ucd_req_ptr->header.dword_2 =
+   UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len);
+   else
+   ucd_req_ptr->header.dword_2 = 0;


What about READ_DESC?


This patch is changing the value written to "Data Segment Length" field 
in the Basic header section of Query Request UPIU. This is description 
of "Data Segment Length" from UFS device v2.1 spec (JESD220C, 
line#1429-1430): "The Data Segment Length field contains the number of 
valid bytes within the Data Segment of the UPIU". Because we will not be 
sending any data segment in the request UPIU itself for the read 
descriptor hence this field can be zeroed out for descriptor read.
Read length for the "read descriptor" transaction needs to be specified 
(in ) in "LENGTH" of transaction specific fields of query request UPIU.


Thanks,
Subhash
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

2016-09-27 Thread Kiwoong Kim
Hi, Martin.

I think that the patch is correct.
UFS spec says "The Data Segment area is empty" for Read Descriptor.
I have been using similar code with it and it works.
That have been already applied in Android kernel.

Reviewed-by: Kiwoong Kim <kwmad@samsung.com>

Regards.

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Martin K. Petersen
> Sent: Wednesday, September 28, 2016 2:14 PM
> To: subha...@codeaurora.org
> Cc: Zang Leigang; vinholika...@gmail.com; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com; linux-scsi@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-scsi-ow...@vger.kernel.org
> Subject: Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR
> 
> >>>>> "Subhash" == subhashj  <subha...@codeaurora.org> writes:
> 
> Subhash> Looks good to me.
> 
> > -   /* Data segment length */
> > -   ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD(
> > -   0, 0, len >> 8, (u8)len);
> > +   /* Data segment length only need for WRITE_DESC */
> > +   if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC)
> > +   ucd_req_ptr->header.dword_2 =
> > +   UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len);
> > +   else
> > +   ucd_req_ptr->header.dword_2 = 0;
> 
> What about READ_DESC?
> 
> --
> Martin K. PetersenOracle Linux Engineering
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

2016-09-27 Thread Martin K. Petersen
> "Subhash" == subhashj   writes:

Subhash> Looks good to me.

> - /* Data segment length */
> - ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD(
> - 0, 0, len >> 8, (u8)len);
> + /* Data segment length only need for WRITE_DESC */
> + if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC)
> + ucd_req_ptr->header.dword_2 =
> + UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len);
> + else
> + ucd_req_ptr->header.dword_2 = 0;

What about READ_DESC?

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

2016-09-27 Thread subhashj

Looks good to me.
Reviewed-by: Subhash Jadavani 

On 2016-08-25 02:39, Zang Leigang wrote:
Some device may cause a compatibility issue while receiving a Query 
UPIU

with Data Segment which does not expected.

Signed-off-by: Zang Leigang 
---
 drivers/scsi/ufs/ufshcd.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f08d41a..9b21d88 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1266,9 +1266,12 @@ static void
ufshcd_prepare_utp_query_req_upiu(struct ufs_hba *hba,
ucd_req_ptr->header.dword_1 = UPIU_HEADER_DWORD(
0, query->request.query_func, 0, 0);

-   /* Data segment length */
-   ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD(
-   0, 0, len >> 8, (u8)len);
+   /* Data segment length only need for WRITE_DESC */
+   if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC)
+   ucd_req_ptr->header.dword_2 =
+   UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len);
+   else
+   ucd_req_ptr->header.dword_2 = 0;

/* Copy the Query Request buffer as is */
memcpy(_req_ptr->qr, >request.upiu_req,

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html