Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp205615yba; Mon, 20 May 2019 07:23:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqxeVUoU0KGH1rwayjy1ORe+T3P9wuUxrlipni+NNau1ykwJknlld4HyC8K3GyQ+2uT8qXKK X-Received: by 2002:a17:902:aa91:: with SMTP id d17mr73414672plr.251.1558362196541; Mon, 20 May 2019 07:23:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558362196; cv=none; d=google.com; s=arc-20160816; b=HK8qEFtek/KiC5C0MExLigkgHpZeX99dyzKLfVTrQb3aHZ7RaJkrRyj4dXez6ZfsR5 D9r3pKOyrHYXcgCTRP4onwLbHGOV+AV8OlgEqsdQ8nbJhkHcxS765pEAK+tUDS1HvT2/ sRutNzHQl8zuw0go6A/6jml5g1Cb3pcSeMkwV2AtDheJObr2XYnDD92XkVtJkbFDKY6w YRSMgf4pIvdGOTM6VDMQb5CUvfBqpZG4/g8XI3/M1tj+J4FHIdjW9UPKum1L3V74K6V/ td9HC2HUXvtt3PbXd6m9SgRs6+qzwX1voEBr9UHmdCXeTagYMWtB8uhlujETt6DwDjqt 7Ahw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=QLgYHkeyDxq0uI42YnFKlepfgpQtKjfBFsxiH95l5wI=; b=jPsrFq6QK5cpGlDgFSJPc23KtzF2oYXDNxq8Z2oOUyzhuNrI31cf2wRdG/FTScCwq1 pSG9K9/rIA8Jtn55IRiIsYTGp/LZLeQOocl99+QtEw0NhmxC65PdTXzrUozuxIrM3E4O ayflPEAeVnm3cR6g0jYvPteibbS493K6BYkef5ZQqDaYhcQIiP7iSJw0Q/Y/QCTgS5+o ieGsH0y2oGtYzTOiOQF70SIbwz0cNMraYi861A4MSEufSqAjqIpNnZeGn1GNqqFvGXpT 2WaB18ecxOrgZxTqSAdz6BM0H+FDEPkZEmMZCIn/AFsyXlKLgA70vMfkD5NklPXYpqUZ Xy2A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f12si16502610pgs.37.2019.05.20.07.23.00; Mon, 20 May 2019 07:23:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731814AbfETKzH (ORCPT + 99 others); Mon, 20 May 2019 06:55:07 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:8221 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725601AbfETKzH (ORCPT ); Mon, 20 May 2019 06:55:07 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 5D0FE464CDEFA0BA2F09; Mon, 20 May 2019 18:55:05 +0800 (CST) Received: from [127.0.0.1] (10.202.227.238) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.439.0; Mon, 20 May 2019 18:54:59 +0800 Subject: Re: [PATCH] scsi: libsas: no need to join wide port again in sas_ex_discover_dev() To: Jason Yan , , References: <20190518094057.18046-1-yanaijie@huawei.com> CC: , , , , , , , , , From: John Garry Message-ID: <1860c624-1216-bb84-7091-d41a4d43f244@huawei.com> Date: Mon, 20 May 2019 11:54:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20190518094057.18046-1-yanaijie@huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.238] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/05/2019 10:40, Jason Yan wrote: > Since we are processing events synchronously now, the second call of > sas_ex_join_wide_port() in sas_ex_discover_dev() is not needed. There > will be no races with other works in disco workqueue. So remove the > second sas_ex_join_wide_port(). > > I did not change the return value of 'res' to error when discover failed > because we need to continue to discover other phys if one phy discover > failed. So let's keep that logic as before and just add a debug log to > detect the failure. > > Signed-off-by: Jason Yan > --- > drivers/scsi/libsas/sas_expander.c | 24 +++--------------------- > 1 file changed, 3 insertions(+), 21 deletions(-) > > diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c > index 83f2fd70ce76..8f90dd497dfe 100644 > --- a/drivers/scsi/libsas/sas_expander.c > +++ b/drivers/scsi/libsas/sas_expander.c > @@ -1116,27 +1116,9 @@ static int sas_ex_discover_dev(struct domain_device *dev, int phy_id) > break; > } > > - if (child) { > - int i; > - > - for (i = 0; i < ex->num_phys; i++) { > - if (ex->ex_phy[i].phy_state == PHY_VACANT || > - ex->ex_phy[i].phy_state == PHY_NOT_PRESENT) > - continue; > - /* > - * Due to races, the phy might not get added to the > - * wide port, so we add the phy to the wide port here. > - */ > - if (SAS_ADDR(ex->ex_phy[i].attached_sas_addr) == > - SAS_ADDR(child->sas_addr)) { > - ex->ex_phy[i].phy_state= PHY_DEVICE_DISCOVERED; > - if (sas_ex_join_wide_port(dev, i)) > - pr_debug("Attaching ex phy%02d to wide port %016llx\n", > - i, SAS_ADDR(ex->ex_phy[i].attached_sas_addr)); > - } > - } > - } This change looks ok. > - > + if (!child) > + pr_debug("Ex %016llx phy%02d failed to discover\n", > + SAS_ADDR(dev->sas_addr), phy_id); nit: /s/Ex/ex/ In case of "second fanout expander...", before this, we don't attempt to discover, and just disable the PHY. In that case, is the log proper? And, if indeed proper, it would seem to merit a higher log level than debug, maybe notice is better. > return res; > } > >