This patch series replace the previous Query Request and NOP patches:
[PATCH 1/8] scsi: ufs: add support for query
[PATCH 6/8] scsi: ufs: Add support for sending NOP OUT UPIU
[PATCH 7/8] scsi: ufs: Set fDeviceInit flag to initiate device initialization
Major difference -

        Sending the query request via the SCSI vendor specific command can
        cause a deadlock in case the SCSI command queue is blocked and we
        would like to send a query request (for example fDeviceInit in case
        of re-initialization). In addition, usage of a vendor specific SCSI
        command for UFS can cause future conflicts if this vendor specific
        command will be allocated for a different usage.

        The new patch series gets an internal tag for NOP and query requests
        and do not involve the SCSI layer in UFS specific requests transfers.
        This design also resolves the possible deadlock mentioned above.


Changes from v2:
        - Rebased on scsi-misc branche (commit 8c0eb596baa5)
        - Minor addition to structure documentation in ufshcd.h
Changes from v1
        - Allocate a tag for device management commands dynamically instead
          of reserving tag[MAX_QUEUE - 1].
        - Changed the "internal_cmd" naming to "dev_cmd" to avoid confusion
          with other type of internal commands other than NOP and QUERY.

Dolev Raviv (1):
  scsi: ufs: Set fDeviceInit flag to initiate device initialization

Sujit Reddy Thumma (1):
  scsi: ufs: Add support for sending NOP OUT UPIU

 drivers/scsi/ufs/ufs.h    |  127 ++++++-
 drivers/scsi/ufs/ufshcd.c |  886 +++++++++++++++++++++++++++++++++++++++------
 drivers/scsi/ufs/ufshcd.h |   43 ++-
 drivers/scsi/ufs/ufshci.h |    2 +-
 4 files changed, 939 insertions(+), 119 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

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

Reply via email to