Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4342439pxu; Tue, 1 Dec 2020 02:30:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJzafAh5NzCfyNDzc1x6iohinw0iREiLugitcy7g2dGTLpUMVe6b+EplzZFOFQ1hEuRdo5pB X-Received: by 2002:a50:a410:: with SMTP id u16mr2339629edb.274.1606818632963; Tue, 01 Dec 2020 02:30:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606818632; cv=none; d=google.com; s=arc-20160816; b=SdLHxJmimnNo1KgYb96yPOyLRBcVlB6GiS4c5kWn0bLBZa7TA2Keco3Tq5ouOCINVe yNvyyX5pN1S2dRZePc/rivbZAZFrNY9d0kN1fAWJb2X08KXcOhV+4RC/AaDhmS8hEXi/ qmceEOoz+NWCDe31lNw1KcEPHMt06ZM3MN2Ft7o7RgMtG5PwvLUBLuPd7PuPKhstqSlS uWFj8ZWzzhaQet/DjJ1UCly86qvMnk+DVFcgsnJBjZVNVjkh8Obii+H3GnxboYwUAUmS maSc9AYdQMNzfZ+ZYcmsjSfxMorYGyiKqZDm2x0b0zcnKCq8aLPtqwXcAj4X0rvqN11J wqyw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=KJfhfsWh8JvrsT8y1mjARF67xnf9+U6SrrNsfv13OOc=; b=Dcxaz5Q5FugImFEmTmxq6E7NDIdO8QYz4UdOFemLSo+wnkbSSLSx7WXnSUB1qbBYxn 6cAia4GEpVnxs/SikLvuG7N4yfikClOvfG+m8zopghAqpfVB4kI7L3vmGA3xmUzf9IDi VA3oSQQ+z4oYqx6MCzNEGMGPbKRKbBx5h/pl/O8dAsisgIITlGwBDjkgCd9XG++TJ12V zbZdB2w+sbXtK9Pr+Nt2qWIaPFQc5jJNSjAZtTH+RW/qjFqizXyQeadB67C4Kpq7kHgN xm+uMzTZBxliKqaEs6hfhdjmM/FXyuH4Lym7dKXtCoZdNO95kcrZimMPHuCTF984XaTf JP0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=h5+3R0qt; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h28si1011935edj.354.2020.12.01.02.30.10; Tue, 01 Dec 2020 02:30:32 -0800 (PST) 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=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=h5+3R0qt; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729774AbgLAK2Q (ORCPT + 99 others); Tue, 1 Dec 2020 05:28:16 -0500 Received: from fllv0015.ext.ti.com ([198.47.19.141]:47084 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726953AbgLAK2Q (ORCPT ); Tue, 1 Dec 2020 05:28:16 -0500 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 0B1ARHtc026763; Tue, 1 Dec 2020 04:27:17 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1606818437; bh=KJfhfsWh8JvrsT8y1mjARF67xnf9+U6SrrNsfv13OOc=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=h5+3R0qt5yanlSI1Ufb8P9TFvBweJUs5gG5uSbXxRwjhw6ZIUgZP1KkLJd9CuljUz 5hFkW6Bey46zvTQHSDQIqHyePJu8sp1UMueagmhZx7Owic+L5N6BLDWdqexZ/czMv8 xV2BHpdb/Y+khpMmI9f4xXlkbdeAuqtzzw6Yrp7A= Received: from DLEE109.ent.ti.com (dlee109.ent.ti.com [157.170.170.41]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 0B1ARHb3100283 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 1 Dec 2020 04:27:17 -0600 Received: from DLEE104.ent.ti.com (157.170.170.34) by DLEE109.ent.ti.com (157.170.170.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Tue, 1 Dec 2020 04:27:17 -0600 Received: from lelv0326.itg.ti.com (10.180.67.84) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Tue, 1 Dec 2020 04:27:17 -0600 Received: from pratyush-OptiPlex-790.dhcp.ti.com (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 0B1ARCuZ080862; Tue, 1 Dec 2020 04:27:15 -0600 From: Pratyush Yadav To: Tudor Ambarus , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , , CC: Pratyush Yadav Subject: [PATCH v3 1/3] UBI: Do not zero out EC and VID on ECC-ed NOR flashes Date: Tue, 1 Dec 2020 15:57:09 +0530 Message-ID: <20201201102711.8727-2-p.yadav@ti.com> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20201201102711.8727-1-p.yadav@ti.com> References: <20201201102711.8727-1-p.yadav@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For NOR flashes EC and VID are zeroed out before an erase is issued to make sure UBI does not mistakenly treat the PEB as used and associate it with an LEB. But on some flashes, like the Cypress Semper S28 SPI NOR flash family, multi-pass page programming is not allowed on the default ECC scheme. This means zeroing out these magic numbers will result in the flash throwing a page programming error. Do not zero out EC and VID for such flashes. A writesize > 1 is an indication of an ECC-ed flash. Signed-off-by: Pratyush Yadav Reviewed-by: Tudor Ambarus --- Notes: No changes in v3. Changes in v2: - Use mtd->writesize to check if multi-pass programming can be done instead of using MTD_NO_MULTI_PASS_WRITE. - Remove the assertion that a NOR flash most have writesize of 1. drivers/mtd/ubi/build.c | 4 +--- drivers/mtd/ubi/io.c | 9 ++++++++- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index e85b04e9716b..25fd7816b1f4 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -628,10 +628,8 @@ static int io_init(struct ubi_device *ubi, int max_beb_per1024) ubi->bad_peb_limit = get_bad_peb_limit(ubi, max_beb_per1024); } - if (ubi->mtd->type == MTD_NORFLASH) { - ubi_assert(ubi->mtd->writesize == 1); + if (ubi->mtd->type == MTD_NORFLASH) ubi->nor_flash = 1; - } ubi->min_io_size = ubi->mtd->writesize; ubi->hdrs_min_io_size = ubi->mtd->writesize >> ubi->mtd->subpage_sft; diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c index 14d890b00d2c..2f3312c31e51 100644 --- a/drivers/mtd/ubi/io.c +++ b/drivers/mtd/ubi/io.c @@ -535,7 +535,14 @@ int ubi_io_sync_erase(struct ubi_device *ubi, int pnum, int torture) return -EROFS; } - if (ubi->nor_flash) { + /* + * If the flash is ECC-ed then we have to erase the ECC block before we + * can write to it. But the write is in preparation to an erase in the + * first place. This means we cannot zero out EC and VID before the + * erase and we just have to hope the flash starts erasing from the + * start of the page. + */ + if (ubi->nor_flash && ubi->mtd->writesize == 1) { err = nor_erase_prepare(ubi, pnum); if (err) return err; -- 2.28.0