From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.3ffe.de (0001.3ffe.de [159.69.201.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F2D1B46D540 for ; Wed, 22 Jul 2026 07:34:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.69.201.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784705652; cv=none; b=TVOcMuWKMWW4yBpiC2fOpQCoDWK/yulwc+RWF8fC7TYkViZWzoDEGeALfCcCtE9G2949vhCf+uqhGjO7oY1zuyxF+jmtFkc30dom/PtyVhhnjpXLNy7mHYdydpaJEsIH3bBA7swY7o2wgcDKfv/jYH8gNLPR04WjViJgmDAvmGk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784705652; c=relaxed/simple; bh=bj0hGXuQdaQEnaeoUqyHjx5QcikfSb4jIsPbICoTswI=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:From:To: References:In-Reply-To; b=Rw4lhahjpq/hZKkIQxihzvU17NY5t89/yPT6RtjkkWOa1sEGThZvRwvjeGCeUKR+RN9CDvsBEjwyP/P+wm8nJya6nlcnJcVS/+ok56Lpuq29ATFfzep97aAN2UFKz+rrvE4Y2asqAJJLboFtzeN6dYwrZ+xs0Bw3UQPRHEMZCfQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=kernel.org; spf=pass smtp.mailfrom=walle.cc; arc=none smtp.client-ip=159.69.201.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=walle.cc Received: from localhost (unknown [IPv6:2a02:810b:4320:1000:4685:ff:fe12:5967]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id 7395612F; Wed, 22 Jul 2026 09:34:04 +0200 (CEST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 22 Jul 2026 09:34:04 +0200 Message-Id: Subject: Re: [PATCH RFC 0/3] mtd: spi-nor: allow multiple erase sizes on uniform flashes Cc: , From: "Michael Walle" To: , "Pratyush Yadav" , "Takahiro Kuwano" , "Miquel Raynal" , "Richard Weinberger" , "Vignesh Raghavendra" X-Mailer: aerc 0.20.0 References: <20260720-spi_nor_multisize_erase-v1-0-38d719bfe77b@nokia.com> In-Reply-To: <20260720-spi_nor_multisize_erase-v1-0-38d719bfe77b@nokia.com> Hi, On Mon Jul 20, 2026 at 5:12 PM CEST, Mateusz Litwin via B4 Relay wrote: > Most SPI NOR flashes advertise several erase sizes (e.g. 4 KiB, 32 KiB an= d > 64 KiB) even when the erase map is uniform across the whole device. The > spi-nor driver currently collapses such flashes to a single erase size an= d > uses only that size for every erase request. > > This is a problem on platforms that need a small exposed erasesize for > partition alignment (for example u-boot-env, RouterBoot soft_config, or > boot header partitions) while still wanting fast bulk erases. Today the > usual workaround is to enable MTD_SPI_NOR_USE_4K_SECTORS, which forces 4 = KiB > erases for the entire device and hurts erase performance on large regions= . > > This series introduces MTD_SPI_NOR_MULTI_ERASE_SIZE. When enabled, unifo= rm > flashes keep multiple erase sizes in the driver erase map and pick the > largest suitable erase size for each step of an erase operation, similar = to > what non-uniform flashes already do. Userspace still sees a single > mtd->erasesize (4 KiB when MTD_SPI_NOR_USE_4K_SECTORS is also enabled), b= ut > large aligned portions of an erase request can use 32 KiB or 64 KiB erase > commands internally. > > The series also converts all erase-type opcodes to their 4-byte-address > variants on uniform flashes, so multi-size erases work correctly on devic= es > larger than 16 MiB. > > This is an RFC series. Feedback is especially welcome on whether to merge > patch 1 alone, patches 1+2, or the full series including the patch 3 PoC. > > The series is stacked so maintainers can choose how much to take: > > - Patch 1 adds the Kconfig option, keeps multiple erase types in the > uniform region mask, and converts all erase-type opcodes for 4-byte > addressing. On its own it routes multi-size uniform erases through > spi_nor_erase_multi_sectors(). > - Patch 2 replaces that routing with a dedicated uniform erase flow > (spi_nor_erase_uniform()), reducing CPU and memory overhead. > - Patch 3 is a proof-of-concept optimization on top of patch 2: it > caches the largest uniform erase type per request to skip redundant > spi_nor_find_best_erase_type() calls in bulk-aligned regions. > > Patch 1 follows an OpenWrt pending patch already used in production: > > https://github.com/openwrt/openwrt/blob/main/target/linux/generic/pending= -6.12/402-mtd-spi-nor-write-support-for-minor-aligned-partitions.patch > > MTD_SPI_NOR_MULTI_ERASE_SIZE defaults to N, so existing configurations ar= e > unaffected. No, not a new Kconfig option. Integrate it into the core, adapt the current erase handling. Also, was this assisted by AI tooling? > Tested: backported to a 6.6-based tree on Micron MT25QU02G with > MTD_SPI_NOR_MULTI_ERASE_SIZE enabled and MTD_SPI_NOR_USE_4K_SECTORS Why didn't you test this on the latest kernel? > disabled (mtd->erasesize reports 64 KiB). librsu erases the flash with What is librsu? -michael > the MEMERASE ioctl on the MTD character device, issuing erase requests > smaller than mtd->erasesize (e.g. a 32 KiB boot header region). > mtd_erase() does not enforce erasesize alignment, so these requests reach > the driver, where the previous uniform path rejected them; they now > succeed through spi_nor_is_uniform_erasable() and the multi-size erase > path. Verified writes and erases on the 32 KiB region. > > A few implementation details are worth discussing: > > 1. The previous uniform erase path only required the length to be a > multiple of mtd->erasesize. With MTD_SPI_NOR_MULTI_ERASE_SIZE enabled= , > spi_nor_is_uniform_erasable() instead checks the address and length > against the smallest supported uniform erase size. Requests aligned t= o > mtd->erasesize still pass (it is a multiple of that size), while > callers may now issue erases smaller than mtd->erasesize, as the teste= d > librsu path does. Misaligned requests are rejected rather than > relying on undefined behavior; please report any regressions. > > 2. Patch 3 addresses per-step spi_nor_find_best_erase_type() overhead. > As a PoC it may be dropped, revised, or split out depending on > maintainer feedback. > > 3. Patch 3 calculates the largest erase size on every request. This coul= d > be done once at init. The same applies to the smallest erase size use= d > for request validation. Where to store that data is open for > discussion if such a change is needed. > > 4. spansion_nor_late_init() overrides nor->erase_opcode (and mtd->erasesi= ze) > for flashes larger than 16 MiB. With MTD_SPI_NOR_MULTI_ERASE_SIZE ena= bled, > spi_nor_erase_uniform() sets nor->erase_opcode before each erase, so t= he > late_init value is not used on the erase path. If the SFDP table mask= s > unsupported erase types in 4-byte-address mode, this is not an issue; > otherwise late_init() or erase-type masking may need changes for > Cypress/Spansion parts. > > 5. Some flashes do not support every erase type with 4-byte-address opcod= es. > Unsupported types are masked by clearing erase_type[].size, but the > corresponding erase_mask bit is not cleared. Erases work correctly, b= ut > debugfs can show a set bit in the sector-map erase mask for a type tha= t is > not listed under "erase commands". Fixing that is probably best done = in > a separate patch. > > Signed-off-by: Mateusz Litwin > --- > Mateusz Litwin (3): > mtd: spi-nor: allow multiple erase sizes on uniform flash > mtd: spi-nor: add dedicated multi-size uniform erase path > mtd: spi-nor: skip erase type search in uniform bulk erase > > drivers/mtd/spi-nor/Kconfig | 25 +++++ > drivers/mtd/spi-nor/core.c | 247 +++++++++++++++++++++++++++++++++-----= ------ > 2 files changed, 213 insertions(+), 59 deletions(-) > --- > base-commit: df415c5e1de0f1aeefacb4e6252ff98d38c04437 > change-id: 20260720-spi_nor_multisize_erase-d644cfd4a5fb > > Best regards,