Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp715988imj; Wed, 13 Feb 2019 16:23:08 -0800 (PST) X-Google-Smtp-Source: AHgI3IZO2dEYzCh6K99F97hJhk9MTR4D+E14GXL/ZWvzR5xLwq/XLaRgfKv1U7qCmYn3Y2j7CucH X-Received: by 2002:a63:6a05:: with SMTP id f5mr933035pgc.72.1550103787926; Wed, 13 Feb 2019 16:23:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550103787; cv=none; d=google.com; s=arc-20160816; b=FCvHtgAI4Z+Jy3jIA3p20ke39OB2t6Ntr+MqheztrcKmlaFi1gT4D4aObHXJcWFIut cbt+hKse9ptCOMLCtNpO+1gPVSbpNNTAFqNLFTI3XmQSmyI/GHZKj1tK9u2bmE2TWgvt pHEcZsSFwb/T/2shpYIr5enczx+mwYRZDMbvZkUR4DTo6LJCHo+/bBqTv7mM3AHvJgAr o5SIOpeIhIvZvpPfHVuKJ37v5Rx8e1mLVO/iFbFNiydF0uNYc5Rb6iDA/zDvoJC9sjE7 dleLxq998FcBL/HFtSvne7LFWiE/wz5G+urzrkdyYZ8kf4L6i7bAtKXTJSGIjjOAXqdO VKAg== 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:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=99F7/4Cgj8BMgKKXIw7feNJePNFB7/Lb69jpUy/NjbI=; b=HulP0L8E6HUSMFFnPat3LhQ2QXCqi6yemnVFePTPCyqtY47NjIlgTHc2Ykqu5nMubL 7hviBvE11lvo5BPygJ5g3sx9NaX6PZc34vuXzAk0egAyTWoOeKEHySu4RXEN4FK9qyr4 Ky30JCUtK/fR6PK6vo8FDSnFnCFAiVsNXDDH/t5MTeU+jUOXxCr0hwlq7W1r4sHV2Gvv Awl7VWR5QfMspnQybyP0az8ZJ1uzOLh6FWyYvZTzH6iHFsn6F5/dKuntncOjeH9a3UhR fh6RpPDbrKdCY4t6hMsGGYyaiN8AmTSvkqSm69MVD9b/EmUSPw9NOBwFALEYwAAWrcLA 7PHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=bfs8DVeM; 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 p126si725303pgp.529.2019.02.13.16.22.52; Wed, 13 Feb 2019 16:23:07 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=default header.b=bfs8DVeM; 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 S2389465AbfBMStg (ORCPT + 99 others); Wed, 13 Feb 2019 13:49:36 -0500 Received: from mail.kernel.org ([198.145.29.99]:43676 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2394031AbfBMSpA (ORCPT ); Wed, 13 Feb 2019 13:45:00 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.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 628B6222D2; Wed, 13 Feb 2019 18:44:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1550083499; bh=gGG85TO/KRs/OuiwPthGb4aVTHNgRmStwAEvT/3rkV4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bfs8DVeMrbHsPaVZwfED8VWWAlZe5KgHdEdBmcEdlfWpXXAU/aaBwsduoCEdLEw9v /TxweIEciLh0z7M+yjQpWwLSg0zDAGzPDuf6+VjNdrG7DA1v4SPkJSl2pgh6j5yY/h qVO7BdU6KUCKNNu7c2xjNtvVMNICOVVFn5muj5NY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stefan Roese , Boris Brezillon , Miquel Raynal Subject: [PATCH 4.20 02/50] mtd: spinand: Handle the case where PROGRAM LOAD does not reset the cache Date: Wed, 13 Feb 2019 19:38:07 +0100 Message-Id: <20190213183655.943424211@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190213183655.747168774@linuxfoundation.org> References: <20190213183655.747168774@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.20-stable review patch. If anyone has any objections, please let me know. ------------------ From: Boris Brezillon commit 13c15e07eedf26092054c8c71f2f47edb8388310 upstream. Looks like PROGRAM LOAD (AKA write cache) does not necessarily reset the cache content to 0xFF (depends on vendor implementation), so we must fill the page cache entirely even if we only want to program the data portion of the page, otherwise we might corrupt the BBM or user data previously programmed in OOB area. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Reported-by: Stefan Roese Cc: Signed-off-by: Boris Brezillon Tested-by: Stefan Roese Reviewed-by: Stefan Roese Acked-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman --- drivers/mtd/nand/spi/core.c | 42 ++++++++++++++++++++---------------------- 1 file changed, 20 insertions(+), 22 deletions(-) --- a/drivers/mtd/nand/spi/core.c +++ b/drivers/mtd/nand/spi/core.c @@ -304,24 +304,30 @@ static int spinand_write_to_cache_op(str struct nand_device *nand = spinand_to_nand(spinand); struct mtd_info *mtd = nanddev_to_mtd(nand); struct nand_page_io_req adjreq = *req; - unsigned int nbytes = 0; - void *buf = NULL; + void *buf = spinand->databuf; + unsigned int nbytes; u16 column = 0; int ret; - memset(spinand->databuf, 0xff, - nanddev_page_size(nand) + - nanddev_per_page_oobsize(nand)); + /* + * Looks like PROGRAM LOAD (AKA write cache) does not necessarily reset + * the cache content to 0xFF (depends on vendor implementation), so we + * must fill the page cache entirely even if we only want to program + * the data portion of the page, otherwise we might corrupt the BBM or + * user data previously programmed in OOB area. + */ + nbytes = nanddev_page_size(nand) + nanddev_per_page_oobsize(nand); + memset(spinand->databuf, 0xff, nbytes); + adjreq.dataoffs = 0; + adjreq.datalen = nanddev_page_size(nand); + adjreq.databuf.out = spinand->databuf; + adjreq.ooblen = nanddev_per_page_oobsize(nand); + adjreq.ooboffs = 0; + adjreq.oobbuf.out = spinand->oobbuf; - if (req->datalen) { + if (req->datalen) memcpy(spinand->databuf + req->dataoffs, req->databuf.out, req->datalen); - adjreq.dataoffs = 0; - adjreq.datalen = nanddev_page_size(nand); - adjreq.databuf.out = spinand->databuf; - nbytes = adjreq.datalen; - buf = spinand->databuf; - } if (req->ooblen) { if (req->mode == MTD_OPS_AUTO_OOB) @@ -332,14 +338,6 @@ static int spinand_write_to_cache_op(str else memcpy(spinand->oobbuf + req->ooboffs, req->oobbuf.out, req->ooblen); - - adjreq.ooblen = nanddev_per_page_oobsize(nand); - adjreq.ooboffs = 0; - nbytes += nanddev_per_page_oobsize(nand); - if (!buf) { - buf = spinand->oobbuf; - column = nanddev_page_size(nand); - } } spinand_cache_op_adjust_colum(spinand, &adjreq, &column); @@ -370,8 +368,8 @@ static int spinand_write_to_cache_op(str /* * We need to use the RANDOM LOAD CACHE operation if there's - * more than one iteration, because the LOAD operation resets - * the cache to 0xff. + * more than one iteration, because the LOAD operation might + * reset the cache to 0xff. */ if (nbytes) { column = op.addr.val;