Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp953696pxf; Thu, 18 Mar 2021 16:08:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwvpjKvJb+luAqLZFT3wjQIQXAP/5BWjaVnzVb9XQuJh9LLEHQf4gCFjraOOpquhMAatXD6 X-Received: by 2002:a17:906:3395:: with SMTP id v21mr1061316eja.322.1616108894788; Thu, 18 Mar 2021 16:08:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616108894; cv=none; d=google.com; s=arc-20160816; b=ZhzKpyJ9UlsPCZfcq/JhcbiztXSDb2jj9UQ+i67JCBQlrhb67T8aY/cMCWmJO0BDyf n3AWRfh62F3mh0PoyI8hJbDjX0oYheDRrAQ+0Sr31YcTPIUSKKgSVZkx398jne1KuLLN vcnx2rnpx2Jwf9/guIcknSfilteRtNu4N6nijJys+BUuwBG0XacWifTkU6Wvd8HaQrnB GxUROlWXoO+IP3DBDRyEO+T5JWNBchSBjmIkMPXBnN7nqKcmgPgsvT7QKfw+Win5W+B5 k7VGoVMlYazFJtuF7RqpXQvW33hpcE4oQoSruDJmyBzTdQVqjA3L6kEOEGpeFW4f+25L 0JGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=gFvbKoTbbtISsQgZesBGqRcM9fA6M7gbO6KnRJFUa1c=; b=be4+5FcoaA7LJeNEc0tBBa/NyN5FdyjLE4LPbLNz61nbEFdViKvqZ3VF8877FZL5RK yHaHYgvezhbxHNZCT4oiAk5qvXJchTrRPX8KB5P4aKrqjY9uQQcXKNmOin9iA6pPoE6Z ABNRGg3lhb+IVbsfFvszuIOUU2Dw44QKJ1z7hpLUc5qtwbPCutOt3VDm/usTSdalsals 8fNgQhkIIQu95mGsqMb5fd6AfRb5b5Lv22A09Zq6dVU1kKw1l6KrtlYyAwpnu1hJZdUe 5d/VxodZtn+kUXMZR9EFiKqdM483BXaM0poTbkjwTEioggrsBM7xgnNnGALuR7zHjJJD fkmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=YlOyVgCR; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dt8si2873125ejc.111.2021.03.18.16.07.52; Thu, 18 Mar 2021 16:08:14 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=YlOyVgCR; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231912AbhCRXGw (ORCPT + 99 others); Thu, 18 Mar 2021 19:06:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230195AbhCRXGd (ORCPT ); Thu, 18 Mar 2021 19:06:33 -0400 Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D143DC06174A for ; Thu, 18 Mar 2021 16:06:32 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id a8so2765890oic.11 for ; Thu, 18 Mar 2021 16:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gFvbKoTbbtISsQgZesBGqRcM9fA6M7gbO6KnRJFUa1c=; b=YlOyVgCRI9TJ0J3Us5cFDJz1VNFTvypleCbdrXGB+xHIqvR7fXorMjOEF0pzeTtJfO YUaWp9LhjWJb6Cy0Gm7/qTGgIBF8JOxNE5EEss5na4GnTD0ceXgi6/8qhMF3VBUB1h8Y PFTkikmO/n/9S+q3nRwny22rGpyHIUfVvYy80qqFgNbdWSiVz6wU2gBfQeKgwDGaVWNx hm6iakR4kk/UFtjVaFyxOS2n729tb1tjEJp5xaCCovHcjxbpiXKHfn6rEprAgWoWWKQO z+C4jeCKamNLMLFZF908e8tNtb62HdSMEZY9VjHjAi3mAoKxslPz8yBWaEMEjVSXzkwf HNhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gFvbKoTbbtISsQgZesBGqRcM9fA6M7gbO6KnRJFUa1c=; b=HjTy1fDf2fsuT8jWw4fC7HYHEPPrHl/6lcXOEmrAOPD9KvCnZC2GI0/L/H7edEvX/E oNazmpd6GCHPm2whAJ1wAj3847tloD7ny9gqiTMzfc1MiRMLuCHJiBhzue/YlXrpgbXE OHW8h5wdL3feScdrZ3jNiz1KGUCdcUJkiZYxJ8e0N16FvJAxCsoNbM/A4aQjKXhikqVQ At+yvXRrahLRpbLkR9y2zxmdCaDt9szeDVTlXwxa0s8TtlMLZOo9v3mUDuoNY36BZuZc flYocrYNPp8wHZHfej37ncRCNapCYNFgzEc8O50ib/qOz6SKMgugxb5svHwiPMNA4NSv /7UA== X-Gm-Message-State: AOAM532st5Zk6nD5F6VHb46im5RLlBO7fcoqn0+SfS3UiFVBbQ8DrUCM /XWBTzdRMwXtwbiJYsp+vefZTbjJ6LLYsXLhU+7YWvWoUGKHs14p X-Received: by 2002:aca:47c4:: with SMTP id u187mr4785963oia.136.1616108791883; Thu, 18 Mar 2021 16:06:31 -0700 (PDT) MIME-Version: 1.0 References: <20210316193905.1673600-1-jollys@google.com> <5e2c35b6-a9c4-0637-738b-ff6920635425@huawei.com> <329a6159-7da6-f60d-b1a5-14648b90f052@huawei.com> In-Reply-To: <329a6159-7da6-f60d-b1a5-14648b90f052@huawei.com> From: Jolly Shah Date: Thu, 18 Mar 2021 16:06:20 -0700 Message-ID: Subject: Re: [PATCH] scsi: libsas: Reset num_scatter if libata mark qc as NODATA To: John Garry Cc: jejb@linux.ibm.com, martin.petersen@oracle.com, a.darwish@linutronix.de, Jason Yan , luojiaxing@huawei.com, dan.carpenter@oracle.com, b.zolnierkie@samsung.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi John, On Thu, Mar 18, 2021 at 9:19 AM John Garry wrote: > > On 18/03/2021 00:24, Jolly Shah wrote: > > Hi John, > > > > Thanks for the review. > > > > > > On Wed, Mar 17, 2021 at 4:44 AM John Garry wrote: > >> > >> On 16/03/2021 19:39, Jolly Shah wrote: > >>> When the cache_type for the scsi device is changed, the scsi layer > >>> issues a MODE_SELECT command. The caching mode details are communicated > >>> via a request buffer associated with the scsi command with data > >>> direction set as DMA_TO_DEVICE (scsi_mode_select). When this command > >>> reaches the libata layer, as a part of generic initial setup, libata > >>> layer sets up the scatterlist for the command using the scsi command > >>> (ata_scsi_qc_new). This command is then translated by the libata layer > >>> into ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat). The libata layer > >>> treats this as a non data command (ata_mselect_caching), since it only > >>> needs an ata taskfile to pass the caching on/off information to the > >>> device. It does not need the scatterlist that has been setup, so it does > >>> not perform dma_map_sg on the scatterlist (ata_qc_issue). > >> > >> So if we don't perform the dma_map_sg() on the sgl at this point, then > >> it seems to me that we should not perform for_each_sg() on it either, > >> right? That is still what happens in sas_ata_qc_issue() in this case. > >> > > Hi Jolly Shah, > > > > > Yes that's right. To avoid that, I can add elseif block for > > ATA_PROT_NODATA before for_each_sg() is performed. Currently there's > > existing code block for ATA_PROT_NODATA after for_each_sg() is > > performed, > > reused that to reset num_scatter. Please suggest. > > > > How about just combine the 2x if-else statements into 1x if-elif-else > statement, like: > > > if (ata_is_atapi(qc->tf.protocol)) { > memcpy(task->ata_task.atapi_packet, qc->cdb, qc->dev->cdb_len); > task->total_xfer_len = qc->nbytes; > task->num_scatter = qc->n_elem; > task->data_dir = qc->dma_dir; > } else if (qc->tf.protocol == ATA_PROT_NODATA) { > task->data_dir = DMA_NONE; > } else { > for_each_sg(qc->sg, sg, qc->n_elem, si) > xfer += sg_dma_len(sg); > > task->total_xfer_len = xfer; > task->num_scatter = si; > task->data_dir = qc->dma_dir; > } > Updated in v2. > >>> Unfortunately, > >>> when this command reaches the libsas layer(sas_ata_qc_issue), libsas > >>> layer sees it as a non data command with a scatterlist. It cannot > >>> extract the correct dma length, since the scatterlist has not been > >>> mapped with dma_map_sg for a DMA operation. When this partially > >>> constructed SAS task reaches pm80xx LLDD, it results in below warning. > >>> > >>> "pm80xx_chip_sata_req 6058: The sg list address > >>> start_addr=0x0000000000000000 data_len=0x0end_addr_high=0xffffffff > >>> end_addr_low=0xffffffff has crossed 4G boundary" > >>> > >>> This patch assigns appropriate value to num_sectors for ata non data > >>> commands. > >>> > >>> Signed-off-by: Jolly Shah > >>> --- > >>> drivers/scsi/libsas/sas_ata.c | 6 ++++-- > >>> 1 file changed, 4 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c > >>> index 024e5a550759..94ec08cebbaa 100644 > >>> --- a/drivers/scsi/libsas/sas_ata.c > >>> +++ b/drivers/scsi/libsas/sas_ata.c > >>> @@ -209,10 +209,12 @@ static unsigned int sas_ata_qc_issue(struct ata_queued_cmd *qc) > >>> task->num_scatter = si; > >>> } > >>> > >>> - if (qc->tf.protocol == ATA_PROT_NODATA) > >>> + if (qc->tf.protocol == ATA_PROT_NODATA) { > >>> task->data_dir = DMA_NONE; > >>> - else > >>> + task->num_scatter = 0; > >> > >> task->num_scatter has already been set in this function. Best not set it > >> twice. > >> > > > > Sure. Please suggest if I should update patch to above suggested > > approach. That will avoid setting num_scatter twice. > > > > Thanks, > John > > BTW, could we add a fixes tag? Added in v2. Thanks, Jolly