Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6094152imu; Wed, 30 Jan 2019 08:42:19 -0800 (PST) X-Google-Smtp-Source: ALg8bN6ZlN4FVNBpemPow4sjGdNint10dDALjzGPZyem7nPRPe4oEmIhT+L7h0wvkL4qtMqXt81M X-Received: by 2002:a17:902:2a66:: with SMTP id i93mr30536866plb.113.1548866539134; Wed, 30 Jan 2019 08:42:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548866539; cv=none; d=google.com; s=arc-20160816; b=HQVNnS+rOK645SXaJRtSpWyy0u3wB+A/LVberHbjY06ZasJAQ2XRZRshWaKa192sE9 NHg2k5hkb5uuezbAJ3OKbxKontxr93zeIiJ4k6gRFtL6zV8+iE8Hp+JgJqMj7qvNCafF rGpD5CPpMI6eols0fhS4mLk0rBmkLTUaJAzVPGWu/EcwC+iH+LGHOj6fJt/gxNcvAozH J3W4ERVm7bW6bdRN6US9BhH80p6RDlFhtpjlAgt9xTXeX/8W5wgFbY162lLLoMPn91EN DYfMmqX5eMlxjx7fJrUNOirKc9n2ZihO4/FmTOqrZQhI9oKGwt86adh31agr3b67RPc/ Cv4A== 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=ZCMMalnVeT80IjDRzGls/BRm0LvWl1Pu61TecsXXxi0=; b=c9PxGL3vV69Kk20Ij57zBv4OD1ol4DQzNSk81W6cLmmDQW/Xu8BtJ5LVXDqGEky+ET E2/LKjzbHdWJUyQLENDKbfB73n4TheasJc8DNRjnRM6FFKI0WfQP8eMfjd8LGFz5hC4M E1q0slO+d4XkSvNmP0JFDCk3j6CEHjiN3xM+x7cKxOprmZIAMiTm78PDK2IAgr3fIuGJ j1Im5eK1G+1Ry9isbPHyNUYvwrjqAzrAGQjWhs3tNWcB896OEXCIK4Uoiri4RAAe6G2C 8M2Rll+UY4GjV+qPBRtGcMIr0oIciopX8eQUJCJV4yWQHK+cbt0Q1rlVEmrRI+A1EQ4w m1cw== 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 h1si1866012plt.44.2019.01.30.08.42.03; Wed, 30 Jan 2019 08:42:19 -0800 (PST) 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 S1732099AbfA3Qlb (ORCPT + 99 others); Wed, 30 Jan 2019 11:41:31 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:60774 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731496AbfA3Qlb (ORCPT ); Wed, 30 Jan 2019 11:41:31 -0500 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id E04A2C22CB5F777FFF94; Thu, 31 Jan 2019 00:41:27 +0800 (CST) Received: from [127.0.0.1] (10.202.226.43) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.408.0; Thu, 31 Jan 2019 00:41:21 +0800 Subject: Re: [PATCH v2 3/7] scsi: libsas: optimize the debug print of the revalidate process To: Jason Yan , , References: <20190130082412.9357-1-yanaijie@huawei.com> <20190130082412.9357-4-yanaijie@huawei.com> CC: , , , , , , , , , , , , Ewan Milne , Tomas Henzl From: John Garry Message-ID: <2ffa6821-93d4-7925-d435-e34338f323ec@huawei.com> Date: Wed, 30 Jan 2019 16:41:12 +0000 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: <20190130082412.9357-4-yanaijie@huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.226.43] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/01/2019 08:24, Jason Yan wrote: > sas_rediscover() returns error code if discover failed for a expander > phy. And sas_ex_revalidate_domain() only returns the last phy's error > code. So when sas_revalidate_domain() prints the return value of the > discover process, we do not know if the revalidation for every phy is > successful or not. We just know the last bcast phy revalidation > succeeded or not. > > No need to return a error code for sas_ex_revalidate_domain() and > sas_rediscover(), and just print the debug log for each bcast phy directly > in sas_rediscover(). do we want to know about every PHY, or just the PHY where res != 0? > I don't see any optimisation here. Maybe an improvement. > Signed-off-by: Jason Yan > CC: John Garry > CC: Johannes Thumshirn > CC: Ewan Milne > CC: Christoph Hellwig > CC: Tomas Henzl > CC: Dan Williams > CC: Hannes Reinecke > --- > drivers/scsi/libsas/sas_discover.c | 7 +++---- > drivers/scsi/libsas/sas_expander.c | 11 ++++++----- > include/scsi/libsas.h | 2 +- > 3 files changed, 10 insertions(+), 10 deletions(-) > > diff --git a/drivers/scsi/libsas/sas_discover.c b/drivers/scsi/libsas/sas_discover.c > index 726ada9b8c79..ffc571a12916 100644 > --- a/drivers/scsi/libsas/sas_discover.c > +++ b/drivers/scsi/libsas/sas_discover.c > @@ -500,7 +500,6 @@ static void sas_discover_domain(struct work_struct *work) > > static void sas_revalidate_domain(struct work_struct *work) > { > - int res = 0; > struct sas_discovery_event *ev = to_sas_discovery_event(work); > struct asd_sas_port *port = ev->port; > struct sas_ha_struct *ha = port->ha; > @@ -521,10 +520,10 @@ static void sas_revalidate_domain(struct work_struct *work) > > if (ddev && (ddev->dev_type == SAS_FANOUT_EXPANDER_DEVICE || > ddev->dev_type == SAS_EDGE_EXPANDER_DEVICE)) > - res = sas_ex_revalidate_domain(ddev); > + sas_ex_revalidate_domain(ddev); > > - pr_debug("done REVALIDATING DOMAIN on port %d, pid:%d, res 0x%x\n", > - port->id, task_pid_nr(current), res); > + pr_debug("done REVALIDATING DOMAIN on port %d, pid:%d\n", > + port->id, task_pid_nr(current)); > out: > mutex_unlock(&ha->disco_mutex); > > diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c > index 7b0e6dcef6e6..5cd720f93f96 100644 > --- a/drivers/scsi/libsas/sas_expander.c > +++ b/drivers/scsi/libsas/sas_expander.c > @@ -2062,7 +2062,7 @@ static int sas_rediscover_dev(struct domain_device *dev, int phy_id, bool last) > * first phy,for other phys in this port, we add it to the port to > * forming the wide-port. > */ > -static int sas_rediscover(struct domain_device *dev, const int phy_id) > +static void sas_rediscover(struct domain_device *dev, const int phy_id) > { > struct expander_device *ex = &dev->ex_dev; > struct ex_phy *changed_phy = &ex->ex_phy[phy_id]; > @@ -2090,7 +2090,9 @@ static int sas_rediscover(struct domain_device *dev, const int phy_id) > res = sas_rediscover_dev(dev, phy_id, last); > } else > res = sas_discover_new(dev, phy_id); > - return res; > + > + pr_debug("ex %016llx phy%d discover returned 0x%x\n", Hmmm.. this is not just discover, but also rediscover > + SAS_ADDR(dev->sas_addr), phy_id, res); > } > > /** > @@ -2102,7 +2104,7 @@ static int sas_rediscover(struct domain_device *dev, const int phy_id) > * Discover process only interrogates devices in order to discover the > * domain. > */ > -int sas_ex_revalidate_domain(struct domain_device *port_dev) > +void sas_ex_revalidate_domain(struct domain_device *port_dev) > { > int res; > struct domain_device *dev = NULL; > @@ -2117,11 +2119,10 @@ int sas_ex_revalidate_domain(struct domain_device *port_dev) > res = sas_find_bcast_phy(dev, &phy_id, i, true); this was missed > if (phy_id == -1) > break; > - res = sas_rediscover(dev, phy_id); > + sas_rediscover(dev, phy_id); > i = phy_id + 1; > } while (i < ex->num_phys); > } > - return res; > } > > void sas_smp_handler(struct bsg_job *job, struct Scsi_Host *shost, > diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h > index 420156cea3ee..e557bcb0c266 100644 > --- a/include/scsi/libsas.h > +++ b/include/scsi/libsas.h > @@ -692,7 +692,7 @@ int sas_discover_root_expander(struct domain_device *); > > void sas_init_ex_attr(void); > > -int sas_ex_revalidate_domain(struct domain_device *); > +void sas_ex_revalidate_domain(struct domain_device *); > > void sas_unregister_domain_devices(struct asd_sas_port *port, int gone); > void sas_init_disc(struct sas_discovery *disc, struct asd_sas_port *); >