Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp707524rdb; Fri, 8 Sep 2023 13:50:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGHwJHHiD2JVmYx5jpkUnY4ECcGTUGJc3IQMgI/CweHdis4pICUtjr2WjIfGW1G3P+cfZ6K X-Received: by 2002:a17:90b:198b:b0:269:3cdb:4edf with SMTP id mv11-20020a17090b198b00b002693cdb4edfmr3560129pjb.16.1694206254096; Fri, 08 Sep 2023 13:50:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694206254; cv=none; d=google.com; s=arc-20160816; b=lLaOlP3+1R12JMMsioggG5g+IlMiJLuHw716eq2lI+GrjrEbXT+OFN5I9n3474VkvT 0nZtFIuPhNLjxg7Fsa65zFyQN9rP93jUkwrdY3b6H7BqYuaBfene/TCJEBrtrbOZhYk1 xdnDYU5HpO9OVc068/7Qz98WlMwi8Y1lqOM6K4wSGzbPiNEpDAxNyYkzGuZGzBbgSvTS qkGUR6qwcLh4O2PtvbI7kuLwQgkVc8+DI+b5mGwpVdlknUAFrwhGF/3JRczmOu985oB3 2i2A9JDKBSGCGBoSqW7u1sv1qMIp6tY8889XmNzGe0WqRk/w9AIA5y01Ud8/2hwh5kE5 xF5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=tMqcqGJBWQ8ny4nLWgcUEt4Avug8p3mZ0TfDrFIgCy4=; fh=LuNSX3JVG+htsysoJ/xF51pAKitwHo02H/zRZAOLqDw=; b=kKuR7LBPJRNbLVR68Cg55Ayeoo6l2yRudGiyF8Cc003/x1FkEpjNIcmEGm0Ul8Rzlc dKYGkZymtSydr5FwsXPsHoR60vP6C9aMj9jCcPxl9yiDQ2SWTPVAo7w8Eq8rpFaQfZXa UnFmX9P73Xu0WL9E4k74gfdrE6cYBQqQNI8Zngq/fzolySS+Vz0pz5ms8W1zpRtbXSnR IotAd1c0nKcJXfyQJZe8fBfDhDrb+CyYcRdgyTsELEgS8nUfvKjYMcvZgTx7q7oqEjy+ EU8JzKUcTlvfrwvPzW5LO/QeNkjaVXKiTBXr34/VkkC75ynf5J8amyGLHSCfPPTduXe8 yhvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jl5RuvoZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e3-20020a17090a9a8300b00263cdc45e92si3798266pjp.28.2023.09.08.13.50.41; Fri, 08 Sep 2023 13:50:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jl5RuvoZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241215AbjIHKR1 (ORCPT + 99 others); Fri, 8 Sep 2023 06:17:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231343AbjIHKRZ (ORCPT ); Fri, 8 Sep 2023 06:17:25 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84E331FF0 for ; Fri, 8 Sep 2023 03:16:50 -0700 (PDT) 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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; -- 2.39.2