From patchwork Wed Apr 20 13:47:38 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tudor Ambarus X-Patchwork-Id: 12820266 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0EAA0C433EF for ; Wed, 20 Apr 2022 13:49:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:CC :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=yzIwB7ZJ7e2KFIxvBp24yvbi2oU4jfeh0Su+1ahblcI=; b=M4HyQoJdIF8AEY bDAM6h48LfBb5k1NnGiMa/hrx9JuOMbwpsQeqVzSlLoTvNaksk1EWbC2hEfvPdhkgvBtiG3ToqIh9 hlNeL0KM56R0Cx7T3grs8IXEnAh84dolaRKQErUXLUPoVvaubazg5zS0/GQxbLjaNSsqjTS1AZ2DX RhLls88m/Wg4rliPeW8rttW7BDetJ8dc/7aK2ZCG1iCKMECqs7hs7dWveOktgbQjBSsDswhznUm1L XDeVfVqExdxKlzPghvXg7g7UXwFodJHhUlfVO+D5QUzmvTdKJFlnf1OdQB6yN9CQh02cyUcQVofdw Dw4ZCIBWXw1bNqw1qKag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhAgV-009IUl-Tl; Wed, 20 Apr 2022 13:47:56 +0000 Received: from esa.microchip.iphmx.com ([68.232.154.123]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhAgR-009IS5-PH for linux-arm-kernel@lists.infradead.org; Wed, 20 Apr 2022 13:47:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1650462471; x=1681998471; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=sUJroFoXBzmcyruFohmRbLRJI63W9ZiOK3L36C2txXM=; b=mIFBfRfA8aZjVXXLlNhCfty1uBHTQ8qLLz0V7lpEPrmiiw3Wzi1dUHLN NVdi5n9LaiHjQBh6CaSa3jEHAgDUgcAS2hq8v231Ye04nbezJjkCScGje mvHiMA91A12bXR5aSGmLi4tFcQ8bvpmW3qulDdq5xC+6QeY1xY/3MEh+Z SgGm2gRJIHP6zYEQ/cuKC1OEN5Noka9rX7VoArjGG5J/hjBp38uAWqKp3 2/gntuaOIuZYFUw+9O/4AvzAM03Q64YLDtQCQf6TIWwe7hIxwnStn4SEF RgKvZINTQzpuCTct5ZOVtZWBfmBuc3eIm6IdxKogXYhDIzruFo0/Mm0nf Q==; X-IronPort-AV: E=Sophos;i="5.90,275,1643698800"; d="scan'208";a="92962328" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 20 Apr 2022 06:47:46 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Wed, 20 Apr 2022 06:47:46 -0700 Received: from ROB-ULT-M18064N.mchp-main.com (10.10.115.15) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server id 15.1.2375.17 via Frontend Transport; Wed, 20 Apr 2022 06:47:43 -0700 From: Tudor Ambarus To: , , CC: , , , , "Tudor Ambarus" Subject: [PATCH 1/3] ARM: configs: at91: Remove MTD_BLOCK and use MTD_UBI_BLOCK for read only block FS Date: Wed, 20 Apr 2022 16:47:38 +0300 Message-ID: <20220420134740.193563-1-tudor.ambarus@microchip.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220420_064751_961091_B8024A7E X-CRM114-Status: GOOD ( 11.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Using mtdblock on raw flashes is generally a bad idea as it lacks wear-leveling, bad block handling or power-cut management. What happens when you use mtdblock and you change any sector of your mtdblockX device, is that it reads the whole corresponding eraseblock into the memory, erases the eraseblock, changes the sector in RAM, and writes the whole eraseblock back. If you have a power failure when the eraseblock is being erased, you lose all the block device sectors in it. The flash will likely decay soon because the eraseblocks will wear out. Remove this archaic tool as its use case should rather be only for debug purposes. This means that write-capable block file systems like ext2, ext3, FAT, etc. will no longer be addressed with at91 defconfigs. For read only block filesystems like SquashFS, use MTD_UBI_BLOCK instead and benefit of UBI's bit-flip handling and wear-levelling. Signed-off-by: Tudor Ambarus Acked-by: Nicolas Ferre --- arch/arm/configs/at91_dt_defconfig | 2 +- arch/arm/configs/sama5_defconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig index 549d01be0b47..cf79510631ea 100644 --- a/arch/arm/configs/at91_dt_defconfig +++ b/arch/arm/configs/at91_dt_defconfig @@ -50,13 +50,13 @@ CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y CONFIG_MTD_TESTS=m CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_BLOCK=y CONFIG_MTD_DATAFLASH=y CONFIG_MTD_RAW_NAND=y CONFIG_MTD_NAND_ATMEL=y CONFIG_MTD_SPI_NOR=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_FASTMAP=y +CONFIG_MTD_UBI_BLOCK=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=4 diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig index 03dd80c2a19e..1c4c5a035518 100644 --- a/arch/arm/configs/sama5_defconfig +++ b/arch/arm/configs/sama5_defconfig @@ -57,13 +57,13 @@ CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y CONFIG_MTD_TESTS=m CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_RAW_NAND=y CONFIG_MTD_NAND_ATMEL=y CONFIG_MTD_SPI_NOR=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_FASTMAP=y +CONFIG_MTD_UBI_BLOCK=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=4