From patchwork Fri Jun 14 15:55:04 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: dann frazier X-Patchwork-Id: 1116108 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 45QQDm4Hf2z9s7h; Sat, 15 Jun 2019 01:55:35 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1hboY7-0007mO-T2; Fri, 14 Jun 2019 15:55:31 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1hboY6-0007lu-PX for kernel-team@lists.ubuntu.com; Fri, 14 Jun 2019 15:55:30 +0000 Received: from mail-io1-f71.google.com ([209.85.166.71]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1hboY6-00055b-CJ for kernel-team@lists.ubuntu.com; Fri, 14 Jun 2019 15:55:30 +0000 Received: by mail-io1-f71.google.com with SMTP id n4so3245536ioc.0 for ; Fri, 14 Jun 2019 08:55:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=tEH3l9lo33jL5Wgb4yqtyzwqJA/+Pvn2lZe5N3IK1To=; b=Rv58LXTRi9qkfhVx5QpAmQ9zlNRRprmcYZb5i8en+pTxSL7qkZZwwwer/OGm0GjNmK O44d9cthar45ptDzdA0u8RTsrhk5OMQ7n6slwjqnFKCeD+PDWieF7INF7TZ1rYog5EGt +yOre3dKpYh8crQompwCt3HeZYhr91u0efxvn6vdZ3jxPUSpUpB6iYf3imdEC/hlvRJa jnizkDC14rK3+RjYLckKmSUpGnRN5KRe1dvBBXW0Hbz6d6KlobsFP07zQdxHUpWePFXI HNQ73rwvDYa3lu97ETh9ll7PfLzb03dJ3oAXS2+Kxmfl/E/TqrsH6xRAMB1tcShkxCCl j5Iw== X-Gm-Message-State: APjAAAUqZJmSkvmX25VfCfZCVD+1Z8RapB8EFJmWncNEj95QKOeqg/s8 E/35sQSVmXZtMNfoMhZuDG+/YO4HaBHDMOfxT4u1fHosXTUuW0UtrKM0Qlj1ZqPLryV0VhY+tdQ /xsMyGH9lgdxJjjIIkEv9BUcjtn4prSHq95i8ii6Z9A== X-Received: by 2002:a5e:d507:: with SMTP id e7mr11161752iom.284.1560527729216; Fri, 14 Jun 2019 08:55:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqx2+9QWRxMUS5yr0Ji1ImerLrteAtwtreUeiQIqUBIYq7VUpV7IcaG3iCiMc3qM6IyEi3+Q0w== X-Received: by 2002:a5e:d507:: with SMTP id e7mr11161723iom.284.1560527728832; Fri, 14 Jun 2019 08:55:28 -0700 (PDT) Received: from xps13.canonical.com (c-71-56-235-36.hsd1.co.comcast.net. [71.56.235.36]) by smtp.gmail.com with ESMTPSA id y18sm4983760iob.64.2019.06.14.08.55.28 for (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 14 Jun 2019 08:55:28 -0700 (PDT) From: dann frazier To: kernel-team@lists.ubuntu.com Subject: [PATCH 1/2][SRU Disco] scsi: libsas: Inject revalidate event for root port event Date: Fri, 14 Jun 2019 09:55:04 -0600 Message-Id: <20190614155505.31461-2-dann.frazier@canonical.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190614155505.31461-1-dann.frazier@canonical.com> References: <20190614155505.31461-1-dann.frazier@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: John Garry BugLink: https://bugs.launchpad.net/bugs/1830435 According to the SAS spec, an expander device shall transmit BROADCAST (CHANGE) from at least one phy in each expander port other than the expander port that is the cause for transmitting BROADCAST (CHANGE). As such, for when the link is lost for a root PHY attached to an expander PHY, we get no broadcast event. This causes an issue for libsas, in that we will not revalidate the domain for these events. As a solution, for when a root PHY is formed or deformed from a root port, insert a broadcast event to trigger a domain revalidation. Signed-off-by: John Garry Signed-off-by: Martin K. Petersen (cherry picked from commit 085f104a83d565097644889bf1f6f1aa6d345cb5) Signed-off-by: dann frazier --- drivers/scsi/libsas/sas_port.c | 24 +++++++++++++++++++++--- include/scsi/libsas.h | 7 +++++++ 2 files changed, 28 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/libsas/sas_port.c b/drivers/scsi/libsas/sas_port.c index 03fe479359b6f..38a10478605cb 100644 --- a/drivers/scsi/libsas/sas_port.c +++ b/drivers/scsi/libsas/sas_port.c @@ -95,6 +95,7 @@ static void sas_form_port(struct asd_sas_phy *phy) int i; struct sas_ha_struct *sas_ha = phy->ha; struct asd_sas_port *port = phy->port; + struct domain_device *port_dev; struct sas_internal *si = to_sas_internal(sas_ha->core.shost->transportt); unsigned long flags; @@ -153,8 +154,9 @@ static void sas_form_port(struct asd_sas_phy *phy) } /* add the phy to the port */ + port_dev = port->port_dev; list_add_tail(&phy->port_phy_el, &port->phy_list); - sas_phy_set_target(phy, port->port_dev); + sas_phy_set_target(phy, port_dev); phy->port = port; port->num_phys++; port->phy_mask |= (1U << phy->id); @@ -184,14 +186,21 @@ static void sas_form_port(struct asd_sas_phy *phy) port->phy_mask, SAS_ADDR(port->attached_sas_addr)); - if (port->port_dev) - port->port_dev->pathways = port->num_phys; + if (port_dev) + port_dev->pathways = port->num_phys; /* Tell the LLDD about this port formation. */ if (si->dft->lldd_port_formed) si->dft->lldd_port_formed(phy); sas_discover_event(phy->port, DISCE_DISCOVER_DOMAIN); + /* Only insert a revalidate event after initial discovery */ + if (port_dev && sas_dev_type_is_expander(port_dev->dev_type)) { + struct expander_device *ex_dev = &port_dev->ex_dev; + + ex_dev->ex_change_count = -1; + sas_discover_event(port, DISCE_REVALIDATE_DOMAIN); + } flush_workqueue(sas_ha->disco_q); } @@ -254,6 +263,15 @@ void sas_deform_port(struct asd_sas_phy *phy, int gone) spin_unlock(&port->phy_list_lock); spin_unlock_irqrestore(&sas_ha->phy_port_lock, flags); + /* Only insert revalidate event if the port still has members */ + if (port->port && dev && sas_dev_type_is_expander(dev->dev_type)) { + struct expander_device *ex_dev = &dev->ex_dev; + + ex_dev->ex_change_count = -1; + sas_discover_event(port, DISCE_REVALIDATE_DOMAIN); + } + flush_workqueue(sas_ha->disco_q); + return; } diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h index 3de3b10da19a9..efd9fa1c40c99 100644 --- a/include/scsi/libsas.h +++ b/include/scsi/libsas.h @@ -224,6 +224,13 @@ struct sas_work { struct work_struct work; }; +/* Lots of code duplicates this in the SCSI tree, which can be factored out */ +static inline bool sas_dev_type_is_expander(enum sas_device_type type) +{ + return type == SAS_EDGE_EXPANDER_DEVICE || + type == SAS_FANOUT_EXPANDER_DEVICE; +} + static inline void INIT_SAS_WORK(struct sas_work *sw, void (*fn)(struct work_struct *)) { INIT_WORK(&sw->work, fn); From patchwork Fri Jun 14 15:55:05 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: dann frazier X-Patchwork-Id: 1116110 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 45QQDr3bqlz9sDX; Sat, 15 Jun 2019 01:55:40 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1hboYD-0007pe-1U; Fri, 14 Jun 2019 15:55:37 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1hboY9-0007nB-1I for kernel-team@lists.ubuntu.com; Fri, 14 Jun 2019 15:55:33 +0000 Received: from mail-io1-f69.google.com ([209.85.166.69]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1hboY8-00055s-Je for kernel-team@lists.ubuntu.com; Fri, 14 Jun 2019 15:55:32 +0000 Received: by mail-io1-f69.google.com with SMTP id c5so3174230iom.18 for ; Fri, 14 Jun 2019 08:55:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wg170Dcw0Sx5BUfovP4ztBwbTGK4xr/6AGk6+GCNgkI=; b=qN2YDpNTfSk1utO4et73KVLuAwwQaovoKHgpBsWB1mhWd9HWt7y8Ed0ZLDx50gAd9A nz7BodsZRnmWXz17MYR77MY5WrWrB1kB8dm+6J1IycuImDRvEiFPkX4X9xcQJo5H6iRt sganPL/RLUiPUn07Sa/Vh4yKg1b7iO4Cfv7X0GzYpVdJSKAlcxuEjfziW9d4WCM4+BoY 4YYkWK8IMjMBZv+S7xWTZvW+aqcSlt5Ld7pF0cXpJU+EM0A1a17ClaFhwf+ILyRl2opZ Oxh179tluhYv+K+mJhzY5j93AnMwo/NEPvCTrED547qAXy0KArhDvTZGSjcGQ05U6PPi hYqQ== X-Gm-Message-State: APjAAAWcDIHtoUDel24qujJEP6L8xzYtEDj6PD7T+kJDwGNhN0tZrXIs 0eueSBHpI+Ih4vfw+jFJC6m+mfrX6uI1SogbToGk6gyapjsJOJ1syrguqm+V0mNbNbxeoIccmt8 GrBWfRUpCCFe3YzvL2ugqk4VGASZ4xEc6fqGxpg7Ggg== X-Received: by 2002:a6b:251:: with SMTP id 78mr39957158ioc.185.1560527731449; Fri, 14 Jun 2019 08:55:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqwG7rZLOO/Ckf037TfaBK8caPJPAL8mPsx+wRy9YmKhJou2Ph/+mf2cHnLsw5maYqVEP7lhUA== X-Received: by 2002:a6b:251:: with SMTP id 78mr39957070ioc.185.1560527730337; Fri, 14 Jun 2019 08:55:30 -0700 (PDT) Received: from xps13.canonical.com (c-71-56-235-36.hsd1.co.comcast.net. [71.56.235.36]) by smtp.gmail.com with ESMTPSA id i3sm3986730ion.9.2019.06.14.08.55.29 for (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 14 Jun 2019 08:55:29 -0700 (PDT) From: dann frazier To: kernel-team@lists.ubuntu.com Subject: [PATCH 2/2][SRU Disco] scsi: libsas: Do discovery on empty PHY to update PHY info Date: Fri, 14 Jun 2019 09:55:05 -0600 Message-Id: <20190614155505.31461-3-dann.frazier@canonical.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190614155505.31461-1-dann.frazier@canonical.com> References: <20190614155505.31461-1-dann.frazier@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: John Garry BugLink: https://bugs.launchpad.net/bugs/1830435 When we discover the PHY is empty in sas_rediscover_dev(), the PHY information (like negotiated linkrate) is not updated. As such, for a user examining sysfs for that PHY, they would see incorrect values: root@(none)$ cd /sys/class/sas_phy/phy-0:0:20 root@(none)$ more negotiated_linkrate 3.0 Gbit root@(none)$ echo 0 > enable root@(none)$ more negotiated_linkrate 3.0 Gbit So fix this, simply discover the PHY again, even though we know it's empty; in the above example, this gives us: root@(none)$ more negotiated_linkrate Phy disabled We must do this after unregistering the device associated with the PHY (in sas_unregister_devs_sas_addr()). Signed-off-by: John Garry Signed-off-by: Martin K. Petersen (cherry picked from commit d8649fc1c5e40e691d589ed825998c36a947491c) Signed-off-by: dann frazier --- drivers/scsi/libsas/sas_expander.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c index bc0bdd4eafe62..14185f780b250 100644 --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -2051,6 +2051,11 @@ static int sas_rediscover_dev(struct domain_device *dev, int phy_id, bool last) if ((SAS_ADDR(sas_addr) == 0) || (res == -ECOMM)) { phy->phy_state = PHY_EMPTY; sas_unregister_devs_sas_addr(dev, phy_id, last); + /* + * Even though the PHY is empty, for convenience we discover + * the PHY to update the PHY info, like negotiated linkrate. + */ + sas_ex_phy_discover(dev, phy_id); return res; } else if (SAS_ADDR(sas_addr) == SAS_ADDR(phy->attached_sas_addr) && dev_type_flutter(type, phy->attached_dev_type)) {