Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp3460942pxa; Wed, 26 Aug 2020 00:28:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHqY+gVZE0TZQL629EtZ8t3JKU2pihdnZM19lv1FVVuOIoG+XypNBLDBDxN+Z01dJFjx24 X-Received: by 2002:aa7:d7d3:: with SMTP id e19mr5530676eds.56.1598426889210; Wed, 26 Aug 2020 00:28:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598426889; cv=none; d=google.com; s=arc-20160816; b=r0tkKnM+bcuhE+OQ5XmwJKKAefBBOhnGLUTMWB4v7wPLEIPMi7Wv7awNlR+nLDqyIG zZMGUEh59jEwSz3BQlAg7Heb4p+KZH+84z5TAtXwoQ4uiCGVbLE+HkEjMDyOHj0kXl5/ s8CMe9/IK19iwEd68I7Ub2+Qz+4Lk6e/5aWtEE5ojL4o+jJm38kzR/8KcrF8uCMiuq37 qBpWu9B7bgjevJGsFx5uP/DUauvXmW5VmVPXaBBUadR4c2eTi8siw/NHVqLm/K8uCU4H bnK1UuCdbsG/ooHO+9pwaL35Wkj7TNmyZ/t3jon6inxJEUR/taEvYnx+wtWbFCopms/E Zf3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=avZuSNSZw9tBko8wGvOrOkShVh3DZ44HjWA8pdDfiY8=; b=tPrth3JDydwlR3tip3KvHhm+2jb6m5ij5yXvEL62Ex2iINe6Pp59Y8d5qB1oHjBKZB mIByNrFzAj2v4Vpj5mpip6OZy6TDnXtvmDizx5FdokIMEpfhYUWIFFVDy3UmUoRkCqip 1Medh/X7EG8BNerJyysvjEV3MDvCK8iy57dHgHLBjrN+pRCFI0QLvvtEvDm/9OsM88t4 c5+6kc0IPPvZ9NHZCS2AIKuzvSRbQnw03flQWRynZGwavxEWkxg7hJgY0NtRFjYVumZ4 upDQCA5tYVF6zO0tE/2ECwjrB1U5IWF4HKoaaOhMJ0J6isTrZI1HI8v0mF+ZwE3prWuS JmTw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id za11si442793ejb.367.2020.08.26.00.27.45; Wed, 26 Aug 2020 00:28:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726851AbgHZH0w (ORCPT + 99 others); Wed, 26 Aug 2020 03:26:52 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:57756 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726723AbgHZH0o (ORCPT ); Wed, 26 Aug 2020 03:26:44 -0400 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id EC334B2CAEDE9C0B3083; Wed, 26 Aug 2020 15:26:41 +0800 (CST) Received: from huawei.com (10.69.192.56) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.487.0; Wed, 26 Aug 2020 15:26:35 +0800 From: Luo Jiaxing To: , CC: , , , , , , Subject: [PATCH v1] scsi: libsas: set data_dir as DMA_NONE if libata mark qc as NODATA Date: Wed, 26 Aug 2020 15:24:26 +0800 Message-ID: <1598426666-54544-1-git-send-email-luojiaxing@huawei.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We found that it will fail every time when set feature to SATA disk by "sdparm -s WCE=0 /dev/sde". After checking protocol, we know that MODE SELECT is the SCSI command for setting WCE, and it do not exist in the SATA protocol. Therefore, this commands are encapsulated in the SET FEATURE command in SATA protocol. The difference is that the MODE SELECT command sent to SAS disk contains data and is sent through the DMA. But when send to SATA disk through SET FEATURE command, it does not contain data. I think libsas was not thorough enough in dealing with the situation, at sas_ata_qc_issue(), task->dma_dir is inherited from qc->dma_dir(qc->dma_dir is also inherited from SCSI). However, in ATA driver, if qc->tf.protocol is set to ATA_PROT_NODATA, ata_sg_setup() will not invoked by ata_qc_issue(). It mean that ATA didn't use dma_dir and it's not reliable. So, if libsas still inherits from qc->dma_dir when there is no data need to be send. As a result, task with no data are mistakenly considered as carrying data and it will make LLDD report an error on IO completion. So, When ATA driver mark tf->protocol as NODATA, dma_dir should be set as DMA_NONE. And we can see WCE is successfully disable for SATA disk then. Euler:~ # sdparm -s WCE=0 /dev/sde /dev/sde: ATA ST4000NM0035-1V4 TN03 Euler:~ # sdparm /dev/sde /dev/sde: ATA ST4000NM0035-1V4 TN03 Read write error recovery mode page: AWRE 1 [cha: n, def: 1] ARRE 0 [cha: n, def: 0] PER 0 [cha: n, def: 0] Caching (SBC) mode page: WCE 0 [cha: y, def: 0] RCD 0 [cha: n, def: 0] Control mode page: SWP 0 [cha: n, def: 0] Fixes: fa1c1e8f1ece ("[SCSI] Add SATA support to libsas") Signed-off-by: Luo Jiaxing Reviewed-by: John Garry --- drivers/scsi/libsas/sas_ata.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c index 6a521ba..a488798 100644 --- a/drivers/scsi/libsas/sas_ata.c +++ b/drivers/scsi/libsas/sas_ata.c @@ -209,7 +209,10 @@ static unsigned int sas_ata_qc_issue(struct ata_queued_cmd *qc) task->num_scatter = si; } - task->data_dir = qc->dma_dir; + if (qc->tf.protocol == ATA_PROT_NODATA) + task->data_dir = DMA_NONE; + else + task->data_dir = qc->dma_dir; task->scatter = qc->sg; task->ata_task.retry_count = 1; task->task_state_flags = SAS_TASK_STATE_PENDING; -- 2.7.4