Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2206464ybt; Sun, 28 Jun 2020 11:25:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyu75qXKZuJ7FAGLZmxLwsOHHfJB3WvyHtBNcxWPWUj1I2jLiEB4KXwxFtTB/vQa/fDDgNt X-Received: by 2002:a50:fd07:: with SMTP id i7mr13759519eds.221.1593368717675; Sun, 28 Jun 2020 11:25:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593368717; cv=none; d=google.com; s=arc-20160816; b=xo0Ze8LqB1fj/PzmiByIYTcNg3uPTouEoS1cKNt97sLghO0vQIxCjYjZtE68sZSDWe MDzI103gJe2ACmp6XaEB7DgXBIeacIMZMK5g3WiXIxNgnvYipQtv1HuVdWs4VRpQonVf mLGqX16Gdz3FjPcinaCl50aDaQhY+OZ97oDnailH6BK8qwsN6GngzJuyQN6sQsJkeqD5 bKWAtktXzkzkTCaG4K/FwidhvAh8Rn5wF4HvAYmbjplgkpMFpE+BwjIBBAJuF3ErpoiN xEe2FQ9gUHCKpJAG+zAauSBP6HS1mp53pT6bfZEjolzvASpDsaAQ3CQSqLoFTl/IJojn Z+CQ== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:dkim-signature:dkim-signature; bh=9t7pciCG1E0zNu4oQ07IGz0z9R7oHtfDQoBBiX267b8=; b=YN2q7yUKa9N1nPY6pVwBLay/6TodjoMrCEIJ2EjYsFvAzuqRL28MbZ3K2ZwzmIx8fr 8b33pP/ToyCOGSbLzncMcJVoy0zTR6mXXjxQJsxlUB8Az8+Rkrn6z55fEzGD6Z+l1/AC mTfSJN+tQDTRB2zVMGbnmgBrC2Atz3vlfNs6qqqAw70YQ8esJYYe6NdauM1+kTf+4Iuh 8/FmIu8Vz4sldadOrN5PB6lEyW6TlJzUxYHhTMxmDsf3Dkc3gwmTLJXGiuBBSaBD2hS0 e6ebv3iPu9Ovb62KSzx94D3E7ZCGMI+xCcNb7ykf977lvqnXBJV8N2QOQEQ9qjydjam1 PkQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@octiron.net header.s=20180214 header.b=ge3L2Z21; dkim=pass header.i=@octiron.net header.s=20180214 header.b=gjTDjK1M; 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=pass (p=NONE sp=REJECT dis=NONE) header.from=octiron.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w14si22435012ede.41.2020.06.28.11.24.54; Sun, 28 Jun 2020 11:25:17 -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=@octiron.net header.s=20180214 header.b=ge3L2Z21; dkim=pass header.i=@octiron.net header.s=20180214 header.b=gjTDjK1M; 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=pass (p=NONE sp=REJECT dis=NONE) header.from=octiron.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726666AbgF1SXd (ORCPT + 99 others); Sun, 28 Jun 2020 14:23:33 -0400 Received: from chalk.uuid.uk ([51.68.227.198]:40094 "EHLO chalk.uuid.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726060AbgF1SXc (ORCPT ); Sun, 28 Jun 2020 14:23:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=octiron.net ; s=20180214; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9t7pciCG1E0zNu4oQ07IGz0z9R7oHtfDQoBBiX267b8=; b=ge3L2Z21o6v6QhE6V8vf8PHHaI GPPBiT+BimpjU729m/lFlzwzazoG7yokcNllMERWmvbnI/2HothT9fTMAsOYbnvZGN0x2yWjSvVta gIjkEiQDIj/sOBDAfJaB47CvAujrh6v29/KPwi9lYV7DyvXQKHCD/FUHluLO6z8In1ltfzMY1b7WX OGe2PKLabGZ8R9nlW6lnbe99oabxggtPSYt8neQwXuJ2V0qC/qhZSwnO/Dwoe+jMOrQqS/OjDKttn asa12+EQBhMoou/zuU81+RP0iY0vf0grNimJk80iRa5m93b75wL43LaF1UZTmcokodn4aRrbSXWqJ 5B3GVThg==; Received: by chalk.uuid.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jpbxc-0008Dd-UA; Sun, 28 Jun 2020 19:23:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=octiron.net ; s=20180214; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject; bh=9t7pciCG1E0zNu4oQ07IGz0z9R7oHtfDQoBBiX267b8=; b=gjTDjK1McY2HKRPXenMoIPdr2g V/8jNsz8CBGUYq0rAfsvxORqHMlWELQroUcuXgPKZfuo06GgtBH5G0SJ97dJRhtSXhvaU08FNaqWX FT2rf9cxcx6+jAL3fL28oVqSrsu0rvvajmm/ADMtrKsqnGHRL+CD1T3tF+ZWmEtd3PlnjimCUbDbK dsLELz3UDBc4qIBHNL6yIAAdt7iKFgqkStR27eKnrxTBQ+01wjgc0/nITcvivfMQqG1+qOyjOeCgF guSS0ecG5wcP/cKJuzn6rEVlVtd575iW38FYl4dgACf2ANm102SygKCJGe4YQa8Lj/9zkmg0etarC ZPVsWa3g==; Received: by tsort.uuid.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jpbxa-0007F9-DC; Sun, 28 Jun 2020 19:23:23 +0100 Subject: Re: [PATCH] scsi: sd: stop SSD (non-rotational) disks before reboot To: Damien Le Moal , "James E.J. Bottomley" , "Martin K. Petersen" , Jonathan Corbet , Linux Kernel Mailing List , "linux-scsi@vger.kernel.org" , "linux-doc@vger.kernel.org" References: <499138c8-b6d5-ef4a-2780-4f750ed337d3@0882a8b5-c6c3-11e9-b005-00805fc181fe> <18da4d78-f3df-967f-e7ea-8f2faaa95d6b@0882a8b5-c6c3-11e9-b005-00805fc181fe> From: Simon Arlott Message-ID: Date: Sun, 28 Jun 2020 19:23:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/06/2020 00:31, Damien Le Moal wrote: > On 2020/06/18 21:26, Simon Arlott wrote: >> I haven't verified it, but the BIOS leaves the power off for several >> seconds which should be long enough for the HDDs to spin down. >> >> I'm less concerned about those suddenly losing power but it would be >> nice to have a stop command sent to them too. > > OK. So maybe the patch should be as simple as changing SYSTEM_RESTART state to > SYSTEM_POWER_OFF if reboot=p is set, no ? Since that is consistent with the fact > that reboot=p will cause power to go off, exactly the same as a regular > shutdown, it seems cleaner and safer to use SYSTEM_POWER_OFF for the entire > system, not just scsi disks. That could be a bit misleading because the power isn't going to stay off. Some of the network drivers have specific WOL behaviour changes for a power off. Power cycling the PSU is not something that every BIOS will do, so it's not that simple. It could be a module parameter but I'd be concerned that some other code will assuming the system should be powered off and all of my reboots will become power off events. -- Simon Arlott