From nobody Tue Dec 16 14:52:17 2025 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 5FBCA2459CF; Fri, 5 Dec 2025 19:39:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764963585; cv=none; b=YrZkhSsTwqkD87m0XeGgJrNYVZq7U0LqasEXLu785YjcpmKxfdin2LU3I/QO2f85efSrzzmp2ykPd0o7VeFI5RgsyiwyeXuZYVD0fhH+IP8kq1PxvK9QSV0qUxUd+WDpJw/WzysxezSui31dqXcBZZ4kPT557Ld7vP1U91/Dnqc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764963585; c=relaxed/simple; bh=ulElZZ6V3nq9rJMP/rkg5tZKYiISdRhCdU5SzeNdOjc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=cOHGUlW5oAYNMaH+pcpdqoqxEf+kd1YDinSEjFfmajpFwFY10JaH2edtWw6j0ILFA1NYZYiUJDoNQQdwwlLBfG+AewE2o9rpZbedE22aJFbr4h5FmkfQ5LHUINnH8pbyaZwL7H2SsQeplSt9QRsjYkWoc3aJocwaKieYU8JSaAU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=rwfR0l88; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="rwfR0l88" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id AF5441A1F9D; Fri, 5 Dec 2025 19:39:41 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 86FAA606AC; Fri, 5 Dec 2025 19:39:41 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id E7219102F17A8; Fri, 5 Dec 2025 20:39:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1764963580; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=qGBKhT3RNIHcjkZ9EmczMf85mf9EwSENJtITDWUwMNE=; b=rwfR0l88X+RfLeOIGJQ8PprYYUukBuV8926iW1SSP/RE5++dAcHwq9Z1T/FaWQmbrQutGz aRubIFfOLGVdHv8hTUByo2ygcNrgQPSPF01zV/FDbdsFozAt10b8J7r+HIa+O+eGi8KqGp mIlr8JimntwKvSR5hqv75F86p8CkeTPTDkQNv/wB5jHkCxNRFxqBpg4Wepl/TJ7UvaIiGS Z/NatzKyehSc8txDt73ytaNKr5xYMhmJWiPgZLMz+mgY+1TAhuFcbc8ZXIg/Qm3I47ML5r z1jb8gqDW4BJN0jPYDnOZs+I9CYc+lm4S0OC8FaZOOyCZOrI3PgIL11bk0HY1A== From: Miquel Raynal Date: Fri, 05 Dec 2025 20:38:52 +0100 Subject: [PATCH RFC 1/8] mtd: spinand: Drop a too strong limitation Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20251205-winbond-v6-18-rc1-cont-read-v1-1-01bc48631c73@bootlin.com> References: <20251205-winbond-v6-18-rc1-cont-read-v1-0-01bc48631c73@bootlin.com> In-Reply-To: <20251205-winbond-v6-18-rc1-cont-read-v1-0-01bc48631c73@bootlin.com> To: Mark Brown , Richard Weinberger , Vignesh Raghavendra , Michael Walle Cc: Tudor Ambarus , Pratyush Yadav , Thomas Petazzoni , Steam Lin , Santhosh Kumar K , linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Miquel Raynal X-Mailer: b4 0.14.3 X-Last-TLS-Session-Version: TLSv1.3 Since continuous reads may sometimes not be able to go past an erase block boundary, it has been decided not to attempt longer reads and if the user request is bigger, it will be split across eraseblocks. As these request will anyway be handled correctly, there is no reason to filter out cases where we would go over a target or a die, so drop this limitation which had a side effect: any request to read more than the content of an eraseblock would simply not benefit from the continuous read feature. Signed-off-by: Miquel Raynal --- drivers/mtd/nand/spi/core.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c index 49ee03a7252b..f19150740979 100644 --- a/drivers/mtd/nand/spi/core.c +++ b/drivers/mtd/nand/spi/core.c @@ -788,6 +788,12 @@ static int spinand_mtd_continuous_page_read(struct mtd= _info *mtd, loff_t from, * Each data read must be a multiple of 4-bytes and full pages should be = read; * otherwise, the data output might get out of sequence from one read com= mand * to another. + * + * Continuous reads never cross LUN boundaries. Some devices don't + * support crossing planes boundaries. Some devices don't even support + * crossing blocks boundaries. The common case being to read through UBI, + * we will very rarely read two consequent blocks or more, so let's only = enable + * continuous reads when reading within the same erase block. */ nanddev_io_for_each_block(nand, NAND_PAGE_READ, from, ops, &iter) { ret =3D spinand_select_target(spinand, iter.req.pos.target); @@ -870,19 +876,6 @@ static bool spinand_use_cont_read(struct mtd_info *mtd= , loff_t from, nanddev_offs_to_pos(nand, from, &start_pos); nanddev_offs_to_pos(nand, from + ops->len - 1, &end_pos); =20 - /* - * Continuous reads never cross LUN boundaries. Some devices don't - * support crossing planes boundaries. Some devices don't even support - * crossing blocks boundaries. The common case being to read through UBI, - * we will very rarely read two consequent blocks or more, so it is safer - * and easier (can be improved) to only enable continuous reads when - * reading within the same erase block. - */ - if (start_pos.target !=3D end_pos.target || - start_pos.plane !=3D end_pos.plane || - start_pos.eraseblock !=3D end_pos.eraseblock) - return false; - return start_pos.page < end_pos.page; } =20 --=20 2.51.1