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=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no 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 49E9FC00A89 for ; Thu, 5 Nov 2020 12:21:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CF9A020729 for ; Thu, 5 Nov 2020 12:21:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="V8jjEVSr" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730418AbgKEMV1 (ORCPT ); Thu, 5 Nov 2020 07:21:27 -0500 Received: from fllv0016.ext.ti.com ([198.47.19.142]:45822 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726067AbgKEMV0 (ORCPT ); Thu, 5 Nov 2020 07:21:26 -0500 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 0A5CL7NJ062582; Thu, 5 Nov 2020 06:21:07 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1604578867; bh=Z4RRec5l05SjKlPI6lwgZrSpZa5Ph7B/vgfrZlgH4EA=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=V8jjEVSrFmvlfWWmuz3412aUGmrlgd35gOcW7Ewo2woR8zFtS+QQpOt+S8yfDWKOa 29JaHlAJCjJDlP/YjVH6JPswMaJRBTP6uP0Jr88md9/y2FJxyLTgNvZSqRx0s9hrOa CaynBYj5X5xdiSz+VLY43Vi3j0FC8Jw8ziiA80NU= Received: from DLEE106.ent.ti.com (dlee106.ent.ti.com [157.170.170.36]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 0A5CL7K8016114 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 5 Nov 2020 06:21:07 -0600 Received: from DLEE115.ent.ti.com (157.170.170.26) by DLEE106.ent.ti.com (157.170.170.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Thu, 5 Nov 2020 06:21:07 -0600 Received: from fllv0039.itg.ti.com (10.64.41.19) by DLEE115.ent.ti.com (157.170.170.26) 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; Thu, 5 Nov 2020 06:21:06 -0600 Received: from [10.250.233.179] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 0A5CL4LN045327; Thu, 5 Nov 2020 06:21:04 -0600 Subject: Re: [PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it To: Pratyush Yadav CC: Richard Weinberger , Tudor Ambarus , Miquel Raynal , Richard Weinberger , , LKML References: <20201012180404.6476-1-p.yadav@ti.com> <20201027111804.e27pyvf62eksngmp@ti.com> <20201103124527.x6mp6slck44aotzn@ti.com> From: Vignesh Raghavendra Message-ID: <4c0e3207-72a4-8c1a-5fca-e9f30cc60828@ti.com> Date: Thu, 5 Nov 2020 17:51:03 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201103124527.x6mp6slck44aotzn@ti.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/3/20 6:15 PM, Pratyush Yadav wrote: > On 03/11/20 05:05PM, Vignesh Raghavendra wrote: >> >> >> On 11/1/20 3:14 AM, Richard Weinberger wrote: >>> On Tue, Oct 27, 2020 at 12:24 PM Pratyush Yadav wrote: >>>>> [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.yadav@ti.com/ >>>> >>>> Ping. Any comments on the series? >>> >>> From the UBIFS point of view I'd like to avoid as many device specific >>> settings as possible. >>> We check already for NOR flash, checking for NOR *and* SPI_NOR_NO_MULTI_PASS_PP >>> feels a bit clumsy. >>> >>> Tudor, what do you think about SPI_NOR_NO_MULTI_PASS_PP? >>> This kind of NOR seems to be a little NAND'ish. Maybe we can hide this detail >>> in the mtd framework? >>> >> >> Agree with Richard. I don't see need for SPI_NOR_NO_MULTI_PASS_PP. From >> MTD point of view setting mtd->writesize to be equal to pagesize should >> be enough. Its upto clients of MTD devices to ensure there is no multi >> pass programming within a "writesize" block. > > That is what I initially thought too but then I realized that multi-pass > programming is completely different from page-size programming. Instead > of writing 4 bytes twice, you can zero out the entire page in one single > operation. You would be compliant with the write size requirement but > you still do multi-pass programming because you did not erase the page > before this operation. > Right... > It is also not completely correct to say the Cypress S28 flash has a > write size of 256. You _can_ write one byte if you want. You just can't > write to that page again without erasing it first. For example, if a > file system only wants to write 128 bytes on a page, it can do so > without having to write the whole page. It just needs to make sure it > doesn't write to it again without erasing first. > As per documentation: mtd_info::writesize: "In case of ECC-ed NOR it is of ECC block size" This means, it is block on which ECC is calculated on ECC-ed NOR and thus needs to be erased every time before being updated. Looking at flash datasheet, this seems to be 16 bytes. So mtd->writesize = 16 and not 256 (or pagesize) Also, It does not imply length of data being written has to be multiple of it. At least NAND subsystem does not seem to care that during writes len < mtd->writesize[1]. > nor_erase_prepare() was written to handle quirks of some specific > devices. Not every device starts filling zeroes from the end of a page. > So we have device-specific code in UBIFS already. You will obviously > need device-specific settings to have control over that code. > UBIFS intends to be robust against rogue power cuts and therefore would need to ensure some consistency during erase which explains flash specific quirk here. > One might argue that we should move nor_erase_prepare() out of UBIFS. > But requiring a flash to start erasing from the start of the page is a > UBIFS-specific requirement. Other users of a flash might not care about > it at all. > Yes. But I don't see much harm done. > And so we have ourselves a bit of a conundrum. Adding > SPI_NOR_NO_MULTI_PASS_PP is IMHO the least disruptive answer. If the > file system wants to do multi-pass page programming on NOR flashes, how > else do we tell it not to do it for this specific flash? > I see don't see need for SPI_NOR_NO_MULTI_PASS_PP as SPI_NOR_NO_MULTI_PASS_PP is implied within a ECC block and writesize is supposed to represent the same. >> If this is not clear in the current documentation of struct mtd, then >> that can be updated. > [1] https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/raw/nand_base.c#L4166