Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp117550pxb; Tue, 28 Sep 2021 17:00:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwez6yu5Qe7m+lfmmeeZHKhhAECqYPgFRGOr59BSPRDGIwE/x+3P3E0fSbOSc2QPImWovug X-Received: by 2002:a05:6402:1c0e:: with SMTP id ck14mr11336542edb.377.1632873624657; Tue, 28 Sep 2021 17:00:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632873624; cv=none; d=google.com; s=arc-20160816; b=dbWv3Yw/VFYqBgBfZR0aBvyFOC4GlDYih6Ia0CSVGJLLMTW25SlIHusSNQFtVKZpOP sH9rwZJPGUv/ydlnlch6YT0MiGGCOMRa6t+TccUdtqvTx35gY9M+sqXfUp8BMNb86STy dpmIac7fMNAn1OegSN7O0jXPvK3pZ/vCWcvH3/g9z7Kd4W0If+KPYOR0beek0tIT4Yq+ WX1vVP/MsnMA+Ewg03nr7jk2ZIF7AYX4I1CIpAz2GYsCWCiFG7s3RfAtbHO0w4nEbMUd 6yiegcWK+KIa5Mjr8/ex18YqkpEZeq7PFYYOw8JPvM8Zyhnl2gizDWp5LnHSQz9DoiDT 5RCA== 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 :message-id:date:subject:cc:to:from:ironport-sdr:dkim-signature; bh=WawVi/k4Q6KWfX7u3fwws9MumNwJ6V6nRDNE4BNm2+4=; b=qXH/Mgb6vf39hrGUTD81IJ94y9ojqBQS/wNIaHGfg7QVc5L9l9A0okuV/aPuSp+0Jg A3k9yTGtIOwTuCn3ngysAdvZvSrOOHTomWom86+AWvSvjPWU4Hv/o0mX1I+GS2kQgU1P qwIGPbi3TqtN1ZigHhtINeQiooXQuB2awDZkvOtNU2ns8BVZx+MeNCWX/oTUceaxUufx Zs6wbNqJIIST38lXzYH5gfYEGVJHU7QCluYokc/mo12eogMou43ceVIGviDAPpNVcAY2 tx/3uzRBUP6DoVzUyMgHrgy6Z7yEBlsidQa1bOZHHFUJ1/eVi1lkLvpiKF+VUImgVMJR JpLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@microchip.com header.s=mchp header.b=oIqP27WS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y12si683498edv.43.2021.09.28.16.59.57; Tue, 28 Sep 2021 17:00:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@microchip.com header.s=mchp header.b=oIqP27WS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243473AbhI1X5G (ORCPT + 99 others); Tue, 28 Sep 2021 19:57:06 -0400 Received: from esa.microchip.iphmx.com ([68.232.154.123]:25123 "EHLO esa.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243330AbhI1X4Y (ORCPT ); Tue, 28 Sep 2021 19:56:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1632873284; x=1664409284; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=hb1FDWgitXO93JdrBImUbsvy8DjbfQuOgUxRuHKy6FY=; b=oIqP27WSHbpyEyce8cfg8f/I2ciTAYruebdRXXaCwhICjsbwqhTMB0Ni /nawHmJd3diJgKRKdfJuuPI51u4S4SUCteRAXjV+JimvcN42x59+3HatD uXLfW3h3epoLUgKDfncYB5ZLPbD9Oq3GRWj+CaQBS6y7Mvj/435WV6cYK pQmaUZY21jjK75qHnMmuwzMd0nJita9QzuI337rQEq2/PozsxQots10GP 1O0PW/GUMTLzSuLbLkw23A6HLCdeA/bTqixfHC4nHvn5x5YaziPwfmdBm 2Sef8ZXDnfXrvMWu+kdUkRK1oVwpWYqRg8ReJbMAgDb+lS8awbG5OxmCj Q==; IronPort-SDR: nYgLiPPRd0zjKz3TcRV3oNRFwlDhPTcRvBwOydMNZlrfNHe+b9tgVk5GFa6qCdr2O1Hk2sm7qb hO5uT14VbfawLz4mx5Yfc1Qyy7HTJMowEnUoS7BUVIkDVjwGLeOPfD51cJvA/HmCQWUFoB9iCL MHvZUx63Z141jI6GcwJWXUl+p+Ri+Ez3m2c/oEXHBiJL0ZT5jkV8zYs7wAwpX9kMK0EFGW9dEx CcljfrGysEzdBhPuPnMJmbZi0qlXuFRAp6tCAaQE8ECrKwKcNsR2g0ldagB3Up4/ALbJTuYHUA HJ+1qKUeycMLwfVO0SmJ6Rkw X-IronPort-AV: E=Sophos;i="5.85,330,1624345200"; d="scan'208";a="131019746" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa4.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 28 Sep 2021 16:54:43 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Tue, 28 Sep 2021 16:54:42 -0700 Received: from brunhilda.pdev.net (10.10.115.15) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server id 15.1.2176.14 via Frontend Transport; Tue, 28 Sep 2021 16:54:42 -0700 Received: by brunhilda.pdev.net (Postfix, from userid 1467) id 584177027D4; Tue, 28 Sep 2021 18:54:42 -0500 (CDT) From: Don Brace To: , , , CC: , , , , , , , , , , , , , , , Subject: [smartpqi updates PATCH V2 00/11] smartpqi updates Date: Tue, 28 Sep 2021 18:54:31 -0500 Message-ID: <20210928235442.201875-1-don.brace@microchip.com> X-Mailer: git-send-email 2.28.0.rc1.9.ge7ae437ac1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org These patches are based on Martin Petersen's 5.16/scsi-queue tree https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 5.16/scsi-queue This set of changes consist of: * Aligning device removal with our out of box driver. * Aligning kdump timing with controller memory dump. The OS was rebooting before the controller was finished dumping its own memory. Now the driver will wait for the controller to indicate that its dump has completed. * In rare cases where the controller stops responding to the driver, the driver can set reason codes to aid in debugging. * Enhance device reset operations. The driver was not obtaining the current number of outstanding commands during the check for outstanding command completions. This was causing reset hangs. * Add in a check for HBA devices undergoing sanitize. This was causing long boot up delays while the OS waited for sanitize to complete. The fix is to check for sanitize and keep the HBA disk offline. Note that the SSA spec states that the disk must be manually re-enabled after sanitize has completed. The link to the spec is noted in the patch. * When the OS off-lines a disk, the SCSI command pointers are cleaned up. The driver was attempting to return some outstanding commands that were no longer valid. * Add in more enhanced report physical luns (RPL) command. This is an internal command that yields more complete WWID information. * Correct a rare case where a poll for a register status before the register has been updated. * When multi-LUN tape devices are added to the OS, the OS does its own report LUNs and the tape devices were duplicated. A simple fix was to update slave_alloc/slave_configure to prevent this. * Add in some new PCI devices. * Bump the driver version. Changes since V1: * Corrected issues with my e-mail server. Don Brace (3): smartpqi: update device removal management smartpqi: add tur check for sanitize operation smartpqi: update version to 2.1.12-055 Kevin Barnett (2): smartpqi: update LUN reset handler smartpqi: fix duplicate device nodes for tape changers Mahesh Rajashekhara (2): smartpqi: add controller handshake during kdump smartpqi: avoid failing ios for offline devices Mike McGowen (3): smartpqi: add extended report physical luns smartpqi: fix boot failure during lun rebuild smartpqi: add 3252-8i pci id Murthy Bhat (1): smartpqi: capture controller reason codes drivers/scsi/smartpqi/smartpqi.h | 61 +- drivers/scsi/smartpqi/smartpqi_init.c | 540 +++++++++++++----- .../scsi/smartpqi/smartpqi_sas_transport.c | 6 +- drivers/scsi/smartpqi/smartpqi_sis.c | 60 +- drivers/scsi/smartpqi/smartpqi_sis.h | 4 +- 5 files changed, 509 insertions(+), 162 deletions(-) -- 2.28.0.rc1.9.ge7ae437ac1