Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp608819rwr; Fri, 5 May 2023 02:08:04 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7vkqYCvPnEnditYVFfT53HJyfdAynA34Uh5c187gHH4gwopRUFPJB+qqEg2PwPaE0CBSYl X-Received: by 2002:a17:902:e810:b0:1a6:7ed0:147e with SMTP id u16-20020a170902e81000b001a67ed0147emr958788plg.33.1683277684584; Fri, 05 May 2023 02:08:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683277684; cv=none; d=google.com; s=arc-20160816; b=AhzpPvZAUA8q5un6uBZKbghJKv1wuo2Z4XFKJ622GTwtGjBbwVrdcuQMksMqVDTsO2 Na7PeqS9mvcA6S4ZkDsnsqW0ZJZ+9apT8dMOoD/yIZTM810fsCvs5bYOXi8aSisJGJ4v HrddYYdXfXrQ3nGYKFonBnCjSeDsAaHAzrQ04c38Fup4XC9zo8nQx4STXd/BDxC1j21h 8QWKuUtG88INtkO7rk0RwEtB49WxmuzAud5ZEtMedSIC1EuZa/7L/oINY4/7gL0H17lP bNyShYI7MuWqLqnaEte0M2ECG4Oah36nbXCTGJRH8GhpZxcAIixkRrdjg8/JOI2ji+g2 t20Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=KwXncxPjiev7uoXHl80K/oU3C7MLPu5CoVe1SeJE6js=; b=X+L3q25YuiDL/K4/xI3rbPufX39bcRUPYxETfdSEkUyUNWwXm+tMd7QbsxTmQ0Jfhh plPOnxkZPR6Qu/VSTCbzMzbgtCYqlZMQbyOilJMGvWHBJiqflZj2Ii+8KUnO8lrKp9uq 5JZk4hYx91K/o+U62YWi1uA2Oa3YMEuIY5YFenCJGfGvcwasaMKicnsuOUBMZBvKSB4u g4VpaTtq+yyw+ERKWnGGbsqna9gwJSYi7oR3ZPVvNuvvCk0cT8ke6DL2kRXNflKlbATj xd+9Q2UpTItgQq3qVd3QeDwpV41rLmkfTXQ5eBCP/Z5reLV58qyWeSsSx4GE3SgF2NJY YmmQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b7-20020a170903228700b001a63d07af3csi1374115plh.41.2023.05.05.02.07.50; Fri, 05 May 2023 02:08:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231579AbjEEJGg (ORCPT + 99 others); Fri, 5 May 2023 05:06:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231578AbjEEJG2 (ORCPT ); Fri, 5 May 2023 05:06:28 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0964D19432; Fri, 5 May 2023 02:06:19 -0700 (PDT) Received: from dggpemm500012.china.huawei.com (unknown [172.30.72.55]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4QCPnx2bPjz18L2Y; Fri, 5 May 2023 17:02:13 +0800 (CST) Received: from [10.67.101.126] (10.67.101.126) by dggpemm500012.china.huawei.com (7.185.36.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 5 May 2023 17:06:17 +0800 Message-ID: <02d36ee9-cdad-454d-d822-95442d7bd67b@huawei.com> Date: Fri, 5 May 2023 17:06:17 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH v2] ata: libata-scsi: Fix get identity data failed Content-Language: en-CA To: Damien Le Moal , , , , CC: , , , , References: <20230505025712.19438-1-yangxingui@huawei.com> <291f1d97-9195-45ac-8e12-058f5c797277@kernel.org> From: yangxingui In-Reply-To: <291f1d97-9195-45ac-8e12-058f5c797277@kernel.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.101.126] X-ClientProxiedBy: dggpemm100017.china.huawei.com (7.185.36.220) To dggpemm500012.china.huawei.com (7.185.36.89) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023/5/5 16:17, Damien Le Moal wrote: > On 2023/05/05 11:57, Xingui Yang wrote: >> The function ata_get_identity() uses the helper ata_scsi_find_dev() to get >> the ata_device structure of a scsi device. However, when the ata device is >> managed by libsas, ata_scsi_find_dev() returns NULL, turning >> ata_get_identity() into a nop and always returns -ENOMSG. > > What do you do to hit the issue ? A while back for me it was the queue depth > setting causing problems. As Garry mentioned, this led to patch 141f3d6256e5 > ("ata: libata-sata: Fix device queue depth control"). Attempt to return the correct value at ata_scsi_find_dev() instead of NULL, when the ata device is managed by libsas? > >> >> Fix this by checking whether ATA_FLAG_SAS_HOST is set for ap->flags in >> ata_scsi_find_dev(), as the flag is only used in libsas. If >> ATA_FLAG_SAS_HOST is set, use sas_to_ata_dev() to find associated ATA >> device. >> >> Signed-off-by: Xingui Yang >> --- >> Changes to v1 >> - Let ata_scsi_find_dev() return the correct value and don't keep replacing >> calls to ata_scsi_find_dev(). >> >> drivers/ata/libata-scsi.c | 12 ++++++++++-- >> drivers/ata/libata.h | 2 +- >> 2 files changed, 11 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c >> index 7bb12deab70c..aa580ea341fa 100644 >> --- a/drivers/ata/libata-scsi.c >> +++ b/drivers/ata/libata-scsi.c >> @@ -26,6 +26,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -2745,10 +2746,17 @@ static struct ata_device *__ata_scsi_find_dev(struct ata_port *ap, >> * Associated ATA device, or %NULL if not found. >> */ >> struct ata_device * >> -ata_scsi_find_dev(struct ata_port *ap, const struct scsi_device *scsidev) > > Why drop the const ? If we use sdev_to_domain_dev(), there will be a compilation warning. But we can replace with scsidev->sdev_target->hostdata. > >> +ata_scsi_find_dev(struct ata_port *ap, struct scsi_device *scsidev) >> { >> - struct ata_device *dev = __ata_scsi_find_dev(ap, scsidev); >> + struct ata_device *dev; >> + >> + if (ap->flags & ATA_FLAG_SAS_HOST) { >> + struct domain_device *ddev = sdev_to_domain_dev(scsidev); >> + >> + return sas_to_ata_dev(ddev); > > Do you really need the ddev variable ? Also, this really should be a libsas > helper. I beleive this pattern is repeated in several places in libsas, so that > would nicely clean things up. As above, we can replace with scsidev->sdev_target->hostdata. Thanks, Xingui > >> + } >> >> + dev = __ata_scsi_find_dev(ap, scsidev); >> if (unlikely(!dev || !ata_dev_enabled(dev))) >> return NULL; >> >> diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h >> index 926d0d33cd29..6d66f46da064 100644 >> --- a/drivers/ata/libata.h >> +++ b/drivers/ata/libata.h >> @@ -109,7 +109,7 @@ static inline void ata_acpi_bind_dev(struct ata_device *dev) {} >> >> /* libata-scsi.c */ >> extern struct ata_device *ata_scsi_find_dev(struct ata_port *ap, >> - const struct scsi_device *scsidev); >> + struct scsi_device *scsidev); >> extern int ata_scsi_add_hosts(struct ata_host *host, >> const struct scsi_host_template *sht); >> extern void ata_scsi_scan_host(struct ata_port *ap, int sync); >