Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2195608iof; Tue, 7 Jun 2022 22:52:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwvbo875VhnQlLRxo7tLI+WyVTstMBuOyXnnAv1/Q/TII+/B7tN6PU1LzDqQ4TW+xRiYgD X-Received: by 2002:a63:e018:0:b0:3fd:94e9:aa0 with SMTP id e24-20020a63e018000000b003fd94e90aa0mr14600000pgh.618.1654667527708; Tue, 07 Jun 2022 22:52:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654667527; cv=none; d=google.com; s=arc-20160816; b=fQ7G3SPHwmk1+/SwH8NfVo5pVo8LKa6jkGMGr3XD8S08sFQdfZR6jt7gjM4HUiH9F7 zKWvqSZkyoHCnlKduZszkOyLTFxmrrDAFa/F8o70k4dfTeCcaXyR2z1sHFOz5ZycZXvi iMWLtC8gZE8bymeEs0NUIs8KGvquelYHG6RHduwx4zRP5c/9gC6LPeB26wDiOX90ROR9 r26Dvubhe1yZ/jGKtMUhRea1jeYXftXmQeM1lWNO/1m+nlaJRFwVlIo9nJCkc3dLs28I xsKvxQQYKHLLgVsJ2Q8+h9oK39QrHMdpLdEBWaugYgnzEB3MsP3YC7FK7dOpge3c84JF UyUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=/d1l0GwHEGP07CQlHcs+zV6z5KyQBvW5QjW0X8vMmJk=; b=npQnUxbSgR53caTv4srR++9W5aykPQAMyy+rIuqqMmOnUgqIMzVFwxAjs1oGA8hKnv ZPs7v0nep4WmKmmQQf+VPEVJqFJfC93MwGl9o+vwo1hl8CcqB5sceQQBaArvCLwn7zIf puBQgLHqyLOsaUiOXpQxGK1V47+RXYriwAmgo6SuaHJRxloqarf7MKcYF/h2WZGHgAJ8 b2tpewGe72lBsQAzvLlyvBoqheESbeWtVUzYpwhNTPL4Rbo5d3D/K4u7bPfWIHQce7jS Sg7VTCnP/zIXYkZ7wXbfzATIgo5rOZCCeCM/X3fkCQ9Zylqn1mlTOeX23lup20S/1kCB Mh4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=elvsiia+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id q1-20020a170902eb8100b00161bc840c77si26452065plg.548.2022.06.07.22.52.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 22:52:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=elvsiia+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CF9F14A9DF5; Tue, 7 Jun 2022 22:18:54 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1392140AbiFHAvt (ORCPT + 99 others); Tue, 7 Jun 2022 20:51:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1383130AbiFGVwT (ORCPT ); Tue, 7 Jun 2022 17:52:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0064D2428D2; Tue, 7 Jun 2022 12:10:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4D431617DA; Tue, 7 Jun 2022 19:10:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5BE74C385A5; Tue, 7 Jun 2022 19:10:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654629033; bh=sbeesrX8k2qss3TrN1ELNXYZUKhfSZzbV0X6jfu5Hrk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=elvsiia+UVhsbSTWLVTgvHniBNin2R8691u6L4oz/9bB8MY6Gt9YrCOEWsdFr7fMF yUO80QB0OIcCeDtbld9HSjATIRgx26Fi2uPsRwHEMf9FXVunEY89HQwg9eZQcG3NQh m78tz3c7F9sc7+4OWfaKQh8JpLA9qutEDQYA3MXA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yihang Li , Xiang Chen , John Garry , "Martin K. Petersen" , Sasha Levin Subject: [PATCH 5.18 504/879] scsi: hisi_sas: Fix rescan after deleting a disk Date: Tue, 7 Jun 2022 19:00:22 +0200 Message-Id: <20220607165017.504815896@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607165002.659942637@linuxfoundation.org> References: <20220607165002.659942637@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 From: John Garry [ Upstream commit e9dedc13bb11bc553754abecb322e5e41d1b4fef ] Removing an ATA device via sysfs means that the device may not be found through re-scanning: root@ubuntu:/home/john# lsscsi [0:0:0:0] disk SanDisk LT0200MO P404 /dev/sda [0:0:1:0] disk ATA HGST HUS724040AL A8B0 /dev/sdb [0:0:8:0] enclosu 12G SAS Expander RevB - root@ubuntu:/home/john# echo 1 > /sys/block/sdb/device/delete root@ubuntu:/home/john# echo "- - -" > /sys/class/scsi_host/host0/scan root@ubuntu:/home/john# lsscsi [0:0:0:0] disk SanDisk LT0200MO P404 /dev/sda [0:0:8:0] enclosu 12G SAS Expander RevB - root@ubuntu:/home/john# The problem is that the rescan of the device may conflict with the device in being re-initialized, as follows: - In the rescan we call hisi_sas_slave_alloc() in store_scan() -> sas_user_scan() -> [__]scsi_scan_target() -> scsi_probe_and_add_lunc() -> scsi_alloc_sdev() -> hisi_sas_slave_alloc() -> hisi_sas_init_device() In hisi_sas_init_device() we issue an IT nexus reset for ATA devices - That IT nexus causes the remote PHY to go down and this triggers a bcast event - In parallel libsas processes the bcast event, finds that the phy is down and marks the device as gone The hard reset issued in hisi_sas_init_device() is unncessary - as described in the code comment - so remove it. Also set dev status as HISI_SAS_DEV_NORMAL as the hisi_sas_init_device() call. Link: https://lore.kernel.org/r/1652354134-171343-4-git-send-email-john.garry@huawei.com Fixes: 36c6b7613ef1 ("scsi: hisi_sas: Initialise devices in .slave_alloc callback") Tested-by: Yihang Li Reviewed-by: Xiang Chen Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin --- drivers/scsi/hisi_sas/hisi_sas_main.c | 47 ++++++++++----------------- 1 file changed, 18 insertions(+), 29 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c index 4bda2f6cb352..86cbfab78dfe 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_main.c +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c @@ -709,8 +709,6 @@ static int hisi_sas_init_device(struct domain_device *device) struct scsi_lun lun; int retry = HISI_SAS_DISK_RECOVER_CNT; struct hisi_hba *hisi_hba = dev_to_hisi_hba(device); - struct device *dev = hisi_hba->dev; - struct sas_phy *local_phy; switch (device->dev_type) { case SAS_END_DEVICE: @@ -729,30 +727,18 @@ static int hisi_sas_init_device(struct domain_device *device) case SAS_SATA_PM_PORT: case SAS_SATA_PENDING: /* - * send HARD RESET to clear previous affiliation of - * STP target port + * If an expander is swapped when a SATA disk is attached then + * we should issue a hard reset to clear previous affiliation + * of STP target port, see SPL (chapter 6.19.4). + * + * However we don't need to issue a hard reset here for these + * reasons: + * a. When probing the device, libsas/libata already issues a + * hard reset in sas_probe_sata() -> ata_sas_async_probe(). + * Note that in hisi_sas_debug_I_T_nexus_reset() we take care + * to issue a hard reset by checking the dev status (== INIT). + * b. When resetting the controller, this is simply unnecessary. */ - local_phy = sas_get_local_phy(device); - if (!scsi_is_sas_phy_local(local_phy) && - !test_bit(HISI_SAS_RESETTING_BIT, &hisi_hba->flags)) { - unsigned long deadline = ata_deadline(jiffies, 20000); - struct sata_device *sata_dev = &device->sata_dev; - struct ata_host *ata_host = sata_dev->ata_host; - struct ata_port_operations *ops = ata_host->ops; - struct ata_port *ap = sata_dev->ap; - struct ata_link *link; - unsigned int classes; - - ata_for_each_link(link, ap, EDGE) - rc = ops->hardreset(link, &classes, - deadline); - } - sas_put_local_phy(local_phy); - if (rc) { - dev_warn(dev, "SATA disk hardreset fail: %d\n", rc); - return rc; - } - while (retry-- > 0) { rc = hisi_sas_softreset_ata_disk(device); if (!rc) @@ -768,15 +754,19 @@ static int hisi_sas_init_device(struct domain_device *device) int hisi_sas_slave_alloc(struct scsi_device *sdev) { - struct domain_device *ddev; + struct domain_device *ddev = sdev_to_domain_dev(sdev); + struct hisi_sas_device *sas_dev = ddev->lldd_dev; int rc; rc = sas_slave_alloc(sdev); if (rc) return rc; - ddev = sdev_to_domain_dev(sdev); - return hisi_sas_init_device(ddev); + rc = hisi_sas_init_device(ddev); + if (rc) + return rc; + sas_dev->dev_status = HISI_SAS_DEV_NORMAL; + return 0; } EXPORT_SYMBOL_GPL(hisi_sas_slave_alloc); @@ -826,7 +816,6 @@ static int hisi_sas_dev_found(struct domain_device *device) dev_info(dev, "dev[%d:%x] found\n", sas_dev->device_id, sas_dev->dev_type); - sas_dev->dev_status = HISI_SAS_DEV_NORMAL; return 0; err_out: -- 2.35.1