Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2307430imm; Thu, 7 Jun 2018 08:31:37 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKrWj+FvEMTG79+E0lQxwfQXKGb15bV2pT8cIKeqLOhjpBWYErTG2qYABBUiHKeJo0AB+CH X-Received: by 2002:a17:902:bc4c:: with SMTP id t12-v6mr2542735plz.177.1528385496989; Thu, 07 Jun 2018 08:31:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528385496; cv=none; d=google.com; s=arc-20160816; b=AD1O6qTRLxvMSVwqPchtcbK0qR2b5/uYqUF4ubqU0Jp13lejh6JUtY3HCTCBnWCYU7 xmzBIfUyYm+EP4oge633cN5dCVwNjMCAf1TVfgTwJ1I1EjoL8nJ2HUoAmTouqh4GKyMi 3+oYwooAPdZsRxzBpG+5PMIo1zNFbuL6AeVL4sbhxa1EU2NabAdTBCP7ZVNRRWrbAg5Q mPRmNTLHDI43DtVNRGi++zPZOP6j3913KFgBiT4j76/t0bAyCGPDfjYIdZnRr/E5lTOz Yr5rY1B/A3GzQA35KyPxWr6PvyWcONmGrL6rTiBH5AvrfVBjiZkjx58E5GkFmerP0+I5 BH5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=/rqkIxiaCXfGVQNc+Obqw2vHJuVnN45OubJDpAGem1A=; b=V3aOoFvi0uvcRtTQGZD+rNYUyVIZhhhu10kMUyQpGdBz8w04Pf4uwU8gr7n3/FmyDy V21qYibhgxLv9Rmjpjx4EOpRVEYFFigr25YXN3E8cPUCWAHQfy7x0OTYgxtZ5KydSh2b SjUHY4TTmhc2jKKuQP1cEZj/soGY4QcBpS3x11uL4HzJxZjW23dCdMb2MKYJeD/dx52z ZU9W0PB279NnssM4tRA39YQzbFd0bK9C4MOeqG2XLVGviX3D55XyUJAWzNqOqd+6OURk 3QQLDLHl96yC+vONDYCQQ3rB2RTbOBUl1FrRSIBoZh+HtuaXv7/d2vXSWU17zomkHIZS ByAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 64-v6si53499640pfl.309.2018.06.07.08.31.22; Thu, 07 Jun 2018 08:31:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935600AbeFGPaF (ORCPT + 99 others); Thu, 7 Jun 2018 11:30:05 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41023 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935391AbeFGOyy (ORCPT ); Thu, 7 Jun 2018 10:54:54 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbM-0005Zk-W6; Thu, 07 Jun 2018 15:09:21 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvbD-0003HC-OQ; Thu, 07 Jun 2018 15:09:11 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Hans de Goede" , "Tejun Heo" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 378/410] libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Hans de Goede commit 62ac3f7305470e3f52f159de448bc1a771717e88 upstream. There have been reports of the Crucial M500 480GB model not working with LPM set to min_power / med_power_with_dipm level. It has not been tested with medium_power, but that typically has no measurable power-savings. Note the reporters Crucial_CT480M500SSD3 has a firmware version of MU03 and there is a MU05 update available, but that update does not mention any LPM fixes in its changelog, so the quirk matches all firmware versions. In my experience the LPM problems with (older) Crucial SSDs seem to be limited to higher capacity versions of the SSDs (different firmware?), so this commit adds a NOLPM quirk for the 480 and 960GB versions of the M500, to avoid LPM causing issues with these SSDs. Reported-and-tested-by: Martin Steigerwald Signed-off-by: Hans de Goede Signed-off-by: Tejun Heo [bwh: Backported to 3.16: There's no ATA_HORKAGE_ZERO_AFTER_TRIM flag] Signed-off-by: Ben Hutchings --- drivers/ata/libata-core.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4231,6 +4231,12 @@ static const struct ata_blacklist_entry { "Crucial_CT512MX100*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_NOLPM, }, + /* 480GB+ M500 SSDs have both queued TRIM and LPM issues */ + { "Crucial_CT480M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | + ATA_HORKAGE_NOLPM, }, + { "Crucial_CT960M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | + ATA_HORKAGE_NOLPM, }, + /* devices that don't properly handle queued TRIM commands */ { "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, }, { "Crucial_CT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, },