From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3F0AC0650F for ; Mon, 5 Aug 2019 13:28:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BABA32075B for ; Mon, 5 Aug 2019 13:28:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565011680; bh=zgnIYBAxB2jrEJmNoprGrBSkqiAFi5O/SGlURM4Rtug=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=CU2u8OcSg41gOduqVJ5+v5zjWfMDRCIOY96lzBYppwDdRjceaTZlj2OtTalRGFiXx p9RhnPPDDH5G+A4MSQR+ZY76wImigQI3uWb2bdPS28RMMpMgxYrQhZDiJGR5f/I9ta LiataBeQtYkCJ1Yk4IheM5C9c7lArqPx/Ulfr7RQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730055AbfHEN14 (ORCPT ); Mon, 5 Aug 2019 09:27:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:60910 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730951AbfHENYJ (ORCPT ); Mon, 5 Aug 2019 09:24:09 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 243712075B; Mon, 5 Aug 2019 13:24:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565011447; bh=zgnIYBAxB2jrEJmNoprGrBSkqiAFi5O/SGlURM4Rtug=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jyHA3Fje9NLfU+Yv0uWgEjQdxtL19Hxk/9LFXlNxjkb5/hM9BtLWCVN6rKm3A4jr3 vYAFo3ahZVQ09hWUfgBOYtLuOguV0782XVlc51vqJdw7IQuN1fmyvz3CcrX2KLCqWr iB1Z3ulZOq7VHUWEL7u6HC1LdVNGXdbGV/mYKTLY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marco Felsch , Boris Brezillon , Miquel Raynal Subject: [PATCH 5.2 092/131] mtd: rawnand: micron: handle on-die "ECC-off" devices correctly Date: Mon, 5 Aug 2019 15:02:59 +0200 Message-Id: <20190805124958.129040120@linuxfoundation.org> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190805124951.453337465@linuxfoundation.org> References: <20190805124951.453337465@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Marco Felsch commit 8493b2a06fc5b77ef5c579dc32b12761f7b7a84c upstream. Some devices are not supposed to support on-die ECC but experience shows that internal ECC machinery can actually be enabled through the "SET FEATURE (EFh)" command, even if a read of the "READ ID Parameter Tables" returns that it is not. Currently, the driver checks the "READ ID Parameter" field directly after having enabled the feature. If the check fails it returns immediately but leaves the ECC on. When using buggy chips like MT29F2G08ABAGA and MT29F2G08ABBGA, all future read/program cycles will go through the on-die ECC, confusing the host controller which is supposed to be the one handling correction. To address this in a common way we need to turn off the on-die ECC directly after reading the "READ ID Parameter" and before checking the "ECC status". Cc: stable@vger.kernel.org Fixes: dbc44edbf833 ("mtd: rawnand: micron: Fix on-die ECC detection logic") Signed-off-by: Marco Felsch Reviewed-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman --- drivers/mtd/nand/raw/nand_micron.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) --- a/drivers/mtd/nand/raw/nand_micron.c +++ b/drivers/mtd/nand/raw/nand_micron.c @@ -390,6 +390,14 @@ static int micron_supports_on_die_ecc(st (chip->id.data[4] & MICRON_ID_INTERNAL_ECC_MASK) != 0x2) return MICRON_ON_DIE_UNSUPPORTED; + /* + * It seems that there are devices which do not support ECC officially. + * At least the MT29F2G08ABAGA / MT29F2G08ABBGA devices supports + * enabling the ECC feature but don't reflect that to the READ_ID table. + * So we have to guarantee that we disable the ECC feature directly + * after we did the READ_ID table command. Later we can evaluate the + * ECC_ENABLE support. + */ ret = micron_nand_on_die_ecc_setup(chip, true); if (ret) return MICRON_ON_DIE_UNSUPPORTED; @@ -398,13 +406,13 @@ static int micron_supports_on_die_ecc(st if (ret) return MICRON_ON_DIE_UNSUPPORTED; - if (!(id[4] & MICRON_ID_ECC_ENABLED)) - return MICRON_ON_DIE_UNSUPPORTED; - ret = micron_nand_on_die_ecc_setup(chip, false); if (ret) return MICRON_ON_DIE_UNSUPPORTED; + if (!(id[4] & MICRON_ID_ECC_ENABLED)) + return MICRON_ON_DIE_UNSUPPORTED; + ret = nand_readid_op(chip, 0, id, sizeof(id)); if (ret) return MICRON_ON_DIE_UNSUPPORTED;