Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6882243imu; Thu, 31 Jan 2019 01:01:39 -0800 (PST) X-Google-Smtp-Source: ALg8bN5oERBr36SglqyKjuJL7pcMCvsFg+5hmQivR4KzePiHydbr84PGmc6ndCqWccEfYnuIN4wd X-Received: by 2002:a17:902:a5c3:: with SMTP id t3mr33397098plq.117.1548925299464; Thu, 31 Jan 2019 01:01:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548925299; cv=none; d=google.com; s=arc-20160816; b=uLGLnjpOf4NpxPXGoaAhgTFT6HThdTMmBCkPXcUf37dJEiSRH1akKi0jhFv43H4jmI tnqALS+cHNsaAGrry69I77+dSjtaRrDS0MFC2fZ5sm9oeHMBe6ngh11bTpnrb1GAy/Qo iw6v+vqyE/OpmO4X3/WpNSwIVIzn2Uc7mDvqipw/B+Yyb60xcwP3KBL69O1OiN7bH2jA I96e79XynIReRn63X9QzoWX/oqv9aKqhxb/R5bUzBtJfOU77zeiKhP9EES/jAzga/rrv 3UY6AWlTDAOCgVAN6xL3mhryKdGFJmMQnhODhsWTVCy0wuegLyZ1hDj5X87UH3oooY1y 5O/w== 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=tLODRE95QOhbdjV3e7WaLjpU2pPrVzKVw4lUQvmSHw8=; b=HalulZfLTUDeyGQ7JqLG+cWARxeNs1UQZf1k6Uvpi6RBU9G5WN5X9bUpHZZG8yU/Gu 3wc8vrN8ZXfkhWI6hyLu1elrEzVZGPxjiYnun0uF5vpEdPzqfUaHYFzeV2eNeT0UndOt 4ZK538oWdGhW/rAUQBXnqY/Uf1qzMNXfAKp3CzmokAv01KU4P7oPmUb+IyCuC4JxTiOY sVXbvcEcMXqED3L55MM7fprDUKW44kt3W1jBkeZqSCdF5N24xSICx36C0dGN3byjT/am KW58Plz9g+EWMLSVmuqC02Ot3c97d2LVcC9hgbBD7SSICGTGdMtqZZaHlUH5OxLUj970 eG+w== 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 y22si3965788pfa.6.2019.01.31.01.01.23; Thu, 31 Jan 2019 01:01:39 -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 S1727623AbfAaJBG (ORCPT + 99 others); Thu, 31 Jan 2019 04:01:06 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:3254 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725787AbfAaJBG (ORCPT ); Thu, 31 Jan 2019 04:01:06 -0500 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id C3373141C5C0E960690E; Thu, 31 Jan 2019 17:01:03 +0800 (CST) Received: from [127.0.0.1] (10.202.226.43) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.408.0; Thu, 31 Jan 2019 17:00:57 +0800 Subject: Re: [PATCH v2 1/7] scsi: libsas: reset the negotiated_linkrate when phy is down To: Jason Yan , , References: <20190130082412.9357-1-yanaijie@huawei.com> <20190130082412.9357-2-yanaijie@huawei.com> <6b06f81e-9ede-014d-b678-1996044106e3@huawei.com> <5C524B3B.5030007@huawei.com> CC: , , , , , , , , , , , , Ewan Milne , Tomas Henzl From: John Garry Message-ID: <21c9fcdb-b0ce-6205-d53a-12ff68b0a5f7@huawei.com> Date: Thu, 31 Jan 2019 09:00:47 +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: <5C524B3B.5030007@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 31/01/2019 01:11, Jason Yan wrote: > > > On 2019/1/30 21:08, John Garry wrote: >> On 30/01/2019 08:24, Jason Yan wrote: >>> If the device is unplugged or disconnected, the negotiated_linkrate >>> still can be seen from the userspace by sysfs. This makes people >>> confused and leaks information of the device last used. So let's reset >>> the negotiated_linkrate after the phy is down. >>> >>> 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_expander.c | 2 ++ >>> include/scsi/libsas.h | 3 +++ >>> 2 files changed, 5 insertions(+) >>> >>> diff --git a/drivers/scsi/libsas/sas_expander.c >>> b/drivers/scsi/libsas/sas_expander.c >>> index 17eb4185f29d..7b0e6dcef6e6 100644 >>> --- a/drivers/scsi/libsas/sas_expander.c >>> +++ b/drivers/scsi/libsas/sas_expander.c >>> @@ -1904,6 +1904,8 @@ static void sas_unregister_devs_sas_addr(struct >>> domain_device *parent, >>> &parent->port->sas_port_del_list); >>> phy->port = NULL; >>> } >>> + if (phy->phy) >>> + phy->phy->negotiated_linkrate = SAS_LINK_RATE_UNKNOWN; >> >> Does this work for both PHYs which were either directly attached or just >> forming part of a wideport? >> >> Please also note that the expander PHY which was previously attached may >> also show the incorrect value. > > Good catch, all PHYs need to do this, not only the last PHY of the > wideport. Please also consider this: - For the expander host PHY, it will also go down. I find however on my system that this generates no broadcast event, but the I find that the event count has changed for that PHY. So the expander PHY's state would also be wrong. So maybe we need to yet again inject a broadcast. - we should update PHY sysfs entries for device_type, sas_addr, and target protocols > >> >>> } >>> >>> static int sas_discover_bfs_by_root_level(struct domain_device *root, >>> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h >>> index 3de3b10da19a..420156cea3ee 100644 >>> --- a/include/scsi/libsas.h >>> +++ b/include/scsi/libsas.h >>> @@ -448,6 +448,9 @@ static inline void sas_phy_disconnected(struct >>> asd_sas_phy *phy) >>> { >>> phy->oob_mode = OOB_NOT_CONNECTED; >>> phy->linkrate = SAS_LINK_RATE_UNKNOWN; >>> + >> >> Then idea behind sas_phy_disconnected() was to set root PHY values only: >> >> /* Before calling a notify event, LLDD should use this function >> * when the link is severed (possibly from its tasklet). >> * The idea is that the Class only reads those, while the LLDD, >> * can R/W these (thus avoiding a race) >> >> libsas does set sas_phy negotiated_linkrate (but only for expander >> PHYs), so not the perfect place to set this. I'm nitpicking a bit here. >> > > I don't want to put it here. I asked chenxiang to fix this in LLDD, but > he insist libsas to do this. Would you please discuss with chenxiang and > come to an agreement? I'm ok with the LLDD. For sure, adding it here is convenient and would resolve the issue for other LLDDs using libsas, but setting it directly in the LLDD seems like the right thing to do, since this is what we do for other sas_phy rates. > >> >>> + if (phy->phy) >>> + phy->phy->negotiated_linkrate = SAS_LINK_RATE_UNKNOWN; >>> } >>> >>> static inline unsigned int to_sas_gpio_od(int device, int bit) >> >> Thanks, >> >>> >> >> >> >> >> >> . >> > > > . >