From patchwork Fri Sep 8 10:16:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Walle X-Patchwork-Id: 1831442 X-Patchwork-Delegate: tudor.ambarus@gmail.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=lMShGwBd; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=jl5RuvoZ; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org; envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=patchwork.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4RhsVW19mxz1ynh for ; Fri, 8 Sep 2023 20:17:23 +1000 (AEST) 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:Cc:To:In-Reply-To:References:Message-Id :MIME-Version:Subject:Date:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=leUg85bnpwdczsx+8CC+2H6IJlPVHKpcierLuDXiAEs=; b=lMShGwBdMBmlh+ dF5kw4x7fausllPKmirw7HsK1OBqQT1c37xWfhHuATdvwu1m4BegF1KPNbmewJoPgFTABB2KfsxFX sKrYjalYjSwrXNFgk2tilnLaPfxc7bNXnZAuZiM53sSQfBZ9sZxFBYHJNj80CAya3T4cfo16v6CcS JpQdJ7kMqq530mwIgSzXxtqSEcUOprMzBUru8DqkuMQTEE18UkOoHXVtSG6HYcISkQm3Vex//xzBk rk5TXHpSSI2AC/xyPiYZwu/jMQ59uIqmi5MbByDiP9fZNfmzo6wDXHUvMgi9w1Pxbw/znleFh0ISv FmSBlxfB89/cSFnPa6Aw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qeYXo-00DSzT-0d; Fri, 08 Sep 2023 10:16:56 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qeYXk-00DSwZ-2F for linux-mtd@lists.infradead.org; Fri, 08 Sep 2023 10:16:54 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3D87CB82038; Fri, 8 Sep 2023 10:16:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37855C433CB; Fri, 8 Sep 2023 10:16:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1694168207; bh=aVw1plMaA1T6kfJ7vhGuu6xOZHiBLnfDGXiBmfum/Cc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=jl5RuvoZyuUEEy+1JWa6GcwTML+nX4N3xLEebul2PzupnpmCF1uX2cLmHWTzwVlwG uz0S0xKGdw+f06NSOFDSF7XpXbCkoFZNx/TmTY7sNG2IlzVCd8D/t/P6zrY7R+Af07 /Zgd26KNkgWA65iL9R6QaFG5SPjpiTLzl6DSu1zCcpXFTbCcEtlal53vl1KgwnzTSe jAChksgUNgUN5pEtigpMAgvGLznxZMfLKZ2FSqvA3ydY9+gTfjKWJC8UUEEs5Reb+9 dH6JP0/UWUnrnjRHSh9QlViGewG8lWOnnTeBN5Mc/kha3mkNtgfYHUQO2ilrbIumuQ U6dCDA8omrt9w== From: Michael Walle Date: Fri, 08 Sep 2023 12:16:27 +0200 Subject: [PATCH v3 09/41] mtd: spi-nor: push 4k SE handling into spi_nor_select_uniform_erase() MIME-Version: 1.0 Message-Id: <20230807-mtd-flash-info-db-rework-v3-9-e60548861b10@kernel.org> References: <20230807-mtd-flash-info-db-rework-v3-0-e60548861b10@kernel.org> In-Reply-To: <20230807-mtd-flash-info-db-rework-v3-0-e60548861b10@kernel.org> To: Tudor Ambarus , Pratyush Yadav , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Michael Walle X-Mailer: b4 0.12.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230908_031653_010557_4D313CEA X-CRM114-Status: GOOD ( 20.74 ) X-Spam-Score: -2.7 (--) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 4k sector erase sizes are only a thing with uniform erase types. Push the "we want 4k erase sizes" handling into spi_nor_select_uniform_erase(). One might wonder why the former sector_size isn't used anymore. It is because we either search for the largest erase size or if selected through kconfig, the 4k erase size. Now, why is that correct? F [...] Content analysis details: (-2.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [2604:1380:4601:e00:0:0:0:1 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.2 DKIMWL_WL_HIGH DKIMwl.org - High trust sender X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org 4k sector erase sizes are only a thing with uniform erase types. Push the "we want 4k erase sizes" handling into spi_nor_select_uniform_erase(). One might wonder why the former sector_size isn't used anymore. It is because we either search for the largest erase size or if selected through kconfig, the 4k erase size. Now, why is that correct? For this, we have to differentiate between (1) flashes with SFDP and (2) without SFDP. For (1), we just set one (or two if SECT_4K is set) erase types and wanted_size is exactly one of these. For (2) things are a bit more complicated. For flashes which we don't have in our flash_info database, the generic driver is used and sector_size was already 0, which in turn selected the largest erase size. For flashes which had SFDP and an entry in flash_info, sector_size was always the largest sector and thus the largest erase type. Signed-off-by: Michael Walle Reviewed-by: Tudor Ambarus --- drivers/mtd/spi-nor/core.c | 27 +++++++++------------------ 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 68baf6032639..c84be791341e 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -2512,13 +2512,6 @@ static int spi_nor_select_pp(struct spi_nor *nor, /** * spi_nor_select_uniform_erase() - select optimum uniform erase type * @map: the erase map of the SPI NOR - * @wanted_size: the erase type size to search for. Contains the value of - * info->sector_size, the "small sector" size in case - * CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is defined or 0 if - * there is no information about the sector size. The - * latter is the case if the flash parameters are parsed - * solely by SFDP, then the largest supported erase type - * is selected. * * Once the optimum uniform sector erase command is found, disable all the * other. @@ -2526,13 +2519,16 @@ static int spi_nor_select_pp(struct spi_nor *nor, * Return: pointer to erase type on success, NULL otherwise. */ static const struct spi_nor_erase_type * -spi_nor_select_uniform_erase(struct spi_nor_erase_map *map, - const u32 wanted_size) +spi_nor_select_uniform_erase(struct spi_nor_erase_map *map) { const struct spi_nor_erase_type *tested_erase, *erase = NULL; int i; u8 uniform_erase_type = map->uniform_erase_type; + /* + * Search for the biggest erase size, except for when compiled + * to use 4k erases. + */ for (i = SNOR_ERASE_TYPE_MAX - 1; i >= 0; i--) { if (!(uniform_erase_type & BIT(i))) continue; @@ -2544,10 +2540,11 @@ spi_nor_select_uniform_erase(struct spi_nor_erase_map *map, continue; /* - * If the current erase size is the one, stop here: + * If the current erase size is the 4k one, stop here, * we have found the right uniform Sector Erase command. */ - if (tested_erase->size == wanted_size) { + if (IS_ENABLED(CONFIG_MTD_SPI_NOR_USE_4K_SECTORS) && + tested_erase->size == SZ_4K) { erase = tested_erase; break; } @@ -2575,7 +2572,6 @@ static int spi_nor_select_erase(struct spi_nor *nor) struct spi_nor_erase_map *map = &nor->params->erase_map; const struct spi_nor_erase_type *erase = NULL; struct mtd_info *mtd = &nor->mtd; - u32 wanted_size = nor->info->sector_size; int i; /* @@ -2586,13 +2582,8 @@ static int spi_nor_select_erase(struct spi_nor *nor) * manage the SPI flash memory as uniform with a single erase sector * size, when possible. */ -#ifdef CONFIG_MTD_SPI_NOR_USE_4K_SECTORS - /* prefer "small sector" erase if possible */ - wanted_size = 4096u; -#endif - if (spi_nor_has_uniform_erase(nor)) { - erase = spi_nor_select_uniform_erase(map, wanted_size); + erase = spi_nor_select_uniform_erase(map); if (!erase) return -EINVAL; nor->erase_opcode = erase->opcode;