From patchwork Fri Jan 4 16:01:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Garry X-Patchwork-Id: 10748423 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 38E2C91E for ; Fri, 4 Jan 2019 16:01:42 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 298C728834 for ; Fri, 4 Jan 2019 16:01:42 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1E2ED28812; Fri, 4 Jan 2019 16:01:42 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9E6A028831 for ; Fri, 4 Jan 2019 16:01:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728465AbfADQBf (ORCPT ); Fri, 4 Jan 2019 11:01:35 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:35485 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727745AbfADQBe (ORCPT ); Fri, 4 Jan 2019 11:01:34 -0500 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 5F1796794278; Sat, 5 Jan 2019 00:01:28 +0800 (CST) Received: from localhost.localdomain (10.67.212.75) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.408.0; Sat, 5 Jan 2019 00:00:25 +0800 From: John Garry To: , CC: , , , , John Garry Subject: [PATCH 1/3] scsi: libsas: Fix some indentation in libsas.h Date: Sat, 5 Jan 2019 00:01:26 +0800 Message-ID: <1546617688-240623-2-git-send-email-john.garry@huawei.com> X-Mailer: git-send-email 2.8.1 In-Reply-To: <1546617688-240623-1-git-send-email-john.garry@huawei.com> References: <1546617688-240623-1-git-send-email-john.garry@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Currently much indentation in this file is done with whitespaces instead of tabs, which can make reading difficult, so fix this up. Some other little minor tidy-up is done, but this file still has many other checkpatch warnings (generally linelength > 80 or function arguments have no identifier names). All libsas code can be audited for checkpatch issues later. Signed-off-by: John Garry --- include/scsi/libsas.h | 56 +++++++++++++++++++++++++-------------------------- 1 file changed, 27 insertions(+), 29 deletions(-) diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h index 3de3b10..857086c 100644 --- a/include/scsi/libsas.h +++ b/include/scsi/libsas.h @@ -52,8 +52,8 @@ enum sas_phy_role { }; enum sas_phy_type { - PHY_TYPE_PHYSICAL, - PHY_TYPE_VIRTUAL + PHY_TYPE_PHYSICAL, + PHY_TYPE_VIRTUAL }; /* The events are mnemonically described in sas_dump.c @@ -91,7 +91,7 @@ enum discover_event { #define to_dom_device(_obj) container_of(_obj, struct domain_device, dev_obj) #define to_dev_attr(_attr) container_of(_attr, struct domain_dev_attribute,\ - attr) + attr) enum routing_attribute { DIRECT_ROUTING, @@ -184,37 +184,37 @@ struct domain_device { spinlock_t done_lock; enum sas_device_type dev_type; - enum sas_linkrate linkrate; - enum sas_linkrate min_linkrate; - enum sas_linkrate max_linkrate; + enum sas_linkrate linkrate; + enum sas_linkrate min_linkrate; + enum sas_linkrate max_linkrate; - int pathways; + int pathways; - struct domain_device *parent; - struct list_head siblings; /* devices on the same level */ - struct asd_sas_port *port; /* shortcut to root of the tree */ + struct domain_device *parent; + struct list_head siblings; /* devices on the same level */ + struct asd_sas_port *port; /* shortcut to root of the tree */ struct sas_phy *phy; - struct list_head dev_list_node; + struct list_head dev_list_node; struct list_head disco_list_node; /* awaiting probe or destruct */ - enum sas_protocol iproto; - enum sas_protocol tproto; + enum sas_protocol iproto; + enum sas_protocol tproto; - struct sas_rphy *rphy; + struct sas_rphy *rphy; - u8 sas_addr[SAS_ADDR_SIZE]; - u8 hashed_sas_addr[HASHED_SAS_ADDR_SIZE]; + u8 sas_addr[SAS_ADDR_SIZE]; + u8 hashed_sas_addr[HASHED_SAS_ADDR_SIZE]; - u8 frame_rcvd[32]; + u8 frame_rcvd[32]; - union { - struct expander_device ex_dev; - struct sata_device sata_dev; /* STP & directly attached */ + union { + struct expander_device ex_dev; + struct sata_device sata_dev; /* STP & directly attached */ struct ssp_device ssp_dev; - }; + }; - void *lldd_dev; + void *lldd_dev; unsigned long state; struct kref kref; }; @@ -512,10 +512,10 @@ enum exec_status { /* When a task finishes with a response, the LLDD examines the * response: - * - For an ATA task task_status_struct::stat is set to + * - For an ATA task task_status_struct::stat is set to * SAS_PROTO_RESPONSE, and the task_status_struct::buf is set to the * contents of struct ata_task_resp. - * - For SSP tasks, if no data is present or status/TMF response + * - For SSP tasks, if no data is present or status/TMF response * is valid, task_status_struct::stat is set. If data is present * (SENSE data), the LLDD copies up to SAS_STATUS_BUF_SIZE, sets * task_status_struct::buf_valid_size, and task_status_struct::stat is @@ -671,15 +671,13 @@ struct sas_domain_function_template { extern void sas_resume_ha(struct sas_ha_struct *sas_ha); extern void sas_suspend_ha(struct sas_ha_struct *sas_ha); -int sas_set_phy_speed(struct sas_phy *phy, - struct sas_phy_linkrates *rates); +int sas_set_phy_speed(struct sas_phy *phy, struct sas_phy_linkrates *rates); int sas_phy_reset(struct sas_phy *phy, int hard_reset); -extern int sas_queuecommand(struct Scsi_Host * ,struct scsi_cmnd *); +extern int sas_queuecommand(struct Scsi_Host *, struct scsi_cmnd *); extern int sas_target_alloc(struct scsi_target *); extern int sas_slave_configure(struct scsi_device *); extern int sas_change_queue_depth(struct scsi_device *, int new_depth); -extern int sas_bios_param(struct scsi_device *, - struct block_device *, +extern int sas_bios_param(struct scsi_device *, struct block_device *, sector_t capacity, int *hsc); extern struct scsi_transport_template * sas_domain_attach_transport(struct sas_domain_function_template *); From patchwork Fri Jan 4 16:01:27 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Garry X-Patchwork-Id: 10748421 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3D36991E for ; Fri, 4 Jan 2019 16:01:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2E6872880A for ; Fri, 4 Jan 2019 16:01:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2264128826; Fri, 4 Jan 2019 16:01:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B95222880A for ; Fri, 4 Jan 2019 16:01:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728382AbfADQBc (ORCPT ); Fri, 4 Jan 2019 11:01:32 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:35486 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727022AbfADQBc (ORCPT ); Fri, 4 Jan 2019 11:01:32 -0500 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 6490D36796A41; Sat, 5 Jan 2019 00:01:28 +0800 (CST) Received: from localhost.localdomain (10.67.212.75) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.408.0; Sat, 5 Jan 2019 00:00:25 +0800 From: John Garry To: , CC: , , , , John Garry Subject: [PATCH 2/3] scsi: libsas: Check SMP PHY control function result Date: Sat, 5 Jan 2019 00:01:27 +0800 Message-ID: <1546617688-240623-3-git-send-email-john.garry@huawei.com> X-Mailer: git-send-email 2.8.1 In-Reply-To: <1546617688-240623-1-git-send-email-john.garry@huawei.com> References: <1546617688-240623-1-git-send-email-john.garry@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Currently the SMP PHY control execution result is checked, however the function result for the command is not. As such, we may be missing all potential errors, like SMP FUNCTION FAILED, INVALID REQUEST FRAME LENGTH, etc., meaning the PHY control request has failed. In some scenarios we need to ensure the function result is accepted, so add a check for this. Tested-by: Jian Luo Signed-off-by: John Garry --- drivers/scsi/libsas/sas_expander.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c index 17eb418..8817b8e 100644 --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -614,7 +614,14 @@ int sas_smp_phy_control(struct domain_device *dev, int phy_id, } res = smp_execute_task(dev, pc_req, PC_REQ_SIZE, pc_resp,PC_RESP_SIZE); - + if (res) { + pr_err("ex %016llx phy%02d PHY control failed: %d\n", + SAS_ADDR(dev->sas_addr), phy_id, res); + } else if (pc_resp[2] != SMP_RESP_FUNC_ACC) { + pr_err("ex %016llx phy%02d PHY control failed: function result 0x%x\n", + SAS_ADDR(dev->sas_addr), phy_id, pc_resp[2]); + res = pc_resp[2]; + } kfree(pc_resp); kfree(pc_req); return res; From patchwork Fri Jan 4 16:01:28 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Garry X-Patchwork-Id: 10748425 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 24C6514E5 for ; Fri, 4 Jan 2019 16:01:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1585728829 for ; Fri, 4 Jan 2019 16:01:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0DCA72882D; Fri, 4 Jan 2019 16:01:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9862F287C1 for ; Fri, 4 Jan 2019 16:01:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728427AbfADQBd (ORCPT ); Fri, 4 Jan 2019 11:01:33 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:35488 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727192AbfADQBc (ORCPT ); Fri, 4 Jan 2019 11:01:32 -0500 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 694635C97288D; Sat, 5 Jan 2019 00:01:28 +0800 (CST) Received: from localhost.localdomain (10.67.212.75) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.408.0; Sat, 5 Jan 2019 00:00:26 +0800 From: John Garry To: , CC: , , , , John Garry Subject: [PATCH 3/3] scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery Date: Sat, 5 Jan 2019 00:01:28 +0800 Message-ID: <1546617688-240623-4-git-send-email-john.garry@huawei.com> X-Mailer: git-send-email 2.8.1 In-Reply-To: <1546617688-240623-1-git-send-email-john.garry@huawei.com> References: <1546617688-240623-1-git-send-email-john.garry@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP +----------+ +----------+ | | | | | |--- 3.0 G ---| |--- 6.0 G --- SAS disk | | | | | |--- 3.0 G ---| |--- 6.0 G --- SAS disk |initiator | | | | device |--- 3.0 G ---| Expander |--- 6.0 G --- SAS disk | | | | | |--- 3.0 G ---| |--- 6.0 G --- SATA disk -->failed to connect | | | | | | | |--- 6.0 G --- SATA disk -->failed to connect | | | | +----------+ +----------+ According to Serial Attached SCSI - 1.1 (SAS-1.1): If an expander PHY attached to a SATA PHY is using a physical link rate greater than the maximum connection rate supported by the pathway from an STP initiator port, a management application client should use the SMP PHY CONTROL function (see 10.4.3.10) to set the PROGRAMMED MAXIMUM PHYSICAL LINK RATE field of the expander PHY to the maximum connection rate supported by the pathway from that STP initiator port. Currently libsas does not support checking if this condition occurs, nor rectifying when it does. Such a condition is not at all common, however it has been seen on some pre-silicon environments where the initiator PHY only supports a 1.5 Gbit maximum linkrate, mated with 12G expander PHYs and 3/6G SATA phy. This patch adds support for checking and rectifying this condition during initial device discovery only. We do support checking min pathway connection rate during revalidation phase, when new devices can be detected in the topology. However we do not support in the case of the the user reprogramming PHY linkrates, such that min pathway condition is not met/maintained. A note on root port PHY rates: The libsas root port PHY rates calculation is broken. Libsas sets the rates (min, max, and current linkrate) of a root port to the same linkrate of the first PHY member of that same port. In doing so, it assumes that all other PHYs which subsequently join the port to have the same negotiated linkrate, when they could actually be different. In practice this doesn't happen, as initiator and expander PHYs are normally initialised with consistent min/max linkrates. This has not caused an issue so far, so leave alone for now. Tested-by: Jian Luo Signed-off-by: John Garry --- drivers/scsi/libsas/sas_expander.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c index 8817b8e..83e3715 100644 --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -824,6 +824,26 @@ static struct domain_device *sas_ex_discover_end_dev( #ifdef CONFIG_SCSI_SAS_ATA if ((phy->attached_tproto & SAS_PROTOCOL_STP) || phy->attached_sata_dev) { + if (child->linkrate > parent->min_linkrate) { + struct sas_phy_linkrates rates = { + .maximum_linkrate = parent->min_linkrate, + .minimum_linkrate = parent->min_linkrate, + }; + int ret; + + pr_notice("ex %016llx phy%02d SATA device linkrate > min pathway connection rate, attempting to lower device linkrate\n", + SAS_ADDR(child->sas_addr), phy_id); + ret = sas_smp_phy_control(parent, phy_id, + PHY_FUNC_LINK_RESET, &rates); + if (ret) { + pr_err("ex %016llx phy%02d SATA device could not set linkrate (%d)\n", + SAS_ADDR(child->sas_addr), phy_id, ret); + goto out_free; + } + pr_notice("ex %016llx phy%02d SATA device set linkrate successfully\n", + SAS_ADDR(child->sas_addr), phy_id); + child->linkrate = child->min_linkrate; + } res = sas_get_ata_info(child, phy); if (res) goto out_free;