From nobody Mon Feb 9 06:50:55 2026 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15512284B58 for ; Sat, 7 Feb 2026 07:04:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770447844; cv=none; b=RKcYq+6v5wxdEXc+poZ0A1U/LaCE0d3nbCYB2AUKAwCSxTjdH15kKrmptj5uDDeQvX0nWjlxDCQoSHYuWjkWmHzsDeEzD/0PVmwP+JmxFoFGxRk6XAcfGB+bBc1zPk/oeWAmmSfkyJCpED7R/K4ueGJEj55jYDpnKx9H2mFX56c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770447844; c=relaxed/simple; bh=BBP4LlqxkGNXahk/sTxiIOnmvXNlKMM6lJ+1xLh3sJs=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=Z3MXqKiTu53o0tOEMJD0S0LRleuBq1nEVmE5MBiXIUVYHh0Jzk+5gSKk6qptPT3tQhKmplmmdTqLO/HIy1POpL/gwL2meCKvlxRDPqnb0zVbID6lQWOdzkCRzcgrRX6lEpBOV1R3L+yaoqrt0tQRz85uy77amzV33EwcijVusRI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CFAfPpzX; arc=none smtp.client-ip=209.85.210.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CFAfPpzX" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-823075fed75so1706906b3a.1 for ; Fri, 06 Feb 2026 23:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770447843; x=1771052643; darn=vger.kernel.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=09LJ83o11Ex+v61x2aS+6WHjo6AYzF1e7mZQxiT7CPg=; b=CFAfPpzXz42SFWI3YdjQRfYFIIFsW5USNXPrfmaJsTlIgXOzEiUaoEI334vAcPcT39 OFb6RmWhQogP72iE/LyjouX1ZMQ49EjSfAZQjTJU7vOZheOJ30AEIno80y+4n/5UYMeT +edzYwe+26ZKldlKzIaqtygSK2jjtEbobcp/JP2Gs/rEYEZmtaMaaY9YQazGVIiy/xFz IYIVaU1BFakJcVaMJBHRE9PoFL8UEFGVm2JrLJtXUxn4JV5Fiywug9bbqj7jQTWKZ+IV yODC/luzMCdSdhMKhtl+ZxEHX/HYQ+ygJeU8C8vXR6BogUlHl3Z8GcU0AEQF0W704dow X5Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770447843; x=1771052643; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=09LJ83o11Ex+v61x2aS+6WHjo6AYzF1e7mZQxiT7CPg=; b=cDjKISJpufGtU2bqmbuJSG8U5ERu5sjK0J71TL/TK2Tp0fNZ4fRAkZnS8HwSJeX0g2 qbPmf5cJhMuHM9N8E4HM5ANBaje3pLADBnPZzP8PJ3jCGgA8LXsKYuo75QNt3Da7ZL1c RsoAcCDxTFyKOznfU7GERpzzNuMZAs8HMG05SP67mnbD/JPn2b64R+28krkxmclbaqtB 3ZJIIu9woeKIBqjRnb2FJOylRpFH9wYnwMdoGbkHZPaHYqGBBqE82BUEVdV6JSx08WCJ KSxi16WDQl/JyYKd2UP+O3ILwZRQgMrZ/3TnZI+y8jXMVsPLipeog8oIoXlNIYr4XkRB J8rQ== X-Forwarded-Encrypted: i=1; AJvYcCXQydnndYs+nneePHFeZ71dgnQEwDUP2n71HYstu9+sYzhSaRtUbjpYqlFPxtKyu4x8kek97TDRG5bktFw=@vger.kernel.org X-Gm-Message-State: AOJu0Yz55ZEJCel7DCWjxHfauKd9bqLr+FcXzt0yAuyxz62kSerLBhRp HOy7Tjuk7Pn4LTHXKkeA7h1mX/FvcFoGMFJrMveGM4JPo+EEHHwNSukS X-Gm-Gg: AZuq6aKOoW3fZiMtqIWyGvv2xx0VIEcvL/j0Pxd/tQDyORb41z8l51lyWrBvgMvjyxv vS8g6Rk34al+vkvM2gJSVfAKjRzGywGtlkwhBNko5QbBcKbXjhUI47xDoTpqoCwPZ3Soo2TLxBX cdUcn5X6ZfUBg5qxBdQ3B6/fF9OmbtXd32Nrb83QMNiCDdIbr6BUT2+TZ5G20kKOuFq5AHnIk/m 9kDapDVr2enIPifHyf/KkNDuVmMQc5iJLjfNG24jP3wdmhU0wo9mtbDllEKTWvdk2J8q8eKSQsS /oSO8O9Ga4qDpGm3XpUDY8vsEREt14bWstD67MvRCLzcA77W/5TRaSZBMjtuXMMf9D4efGXcli/ aco+3iHIzRSd8oRrsuQ1IIUqczNXs//jaziWXP5M9JfiLwMe1ENJ3xg7z35OJEIivBqb8JMoolO O/g6i72dNGOrhCCB8c6PdEh/AR208Wulv/tq2UMHY= X-Received: by 2002:a05:6a00:228c:b0:822:69b2:7ed0 with SMTP id d2e1a72fcca58-82440c1d429mr5231599b3a.6.1770447843215; Fri, 06 Feb 2026 23:04:03 -0800 (PST) Received: from DESKTOP-TIT0J8O.localdomain ([49.47.198.227]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-824418b60easm4250622b3a.55.2026.02.06.23.03.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Feb 2026 23:04:02 -0800 (PST) Date: Sat, 7 Feb 2026 11:02:43 +0400 From: Ahmed Naseef To: Miquel@desktop-tit0j8o.localdomain, Raynal@desktop-tit0j8o.localdomain, miquel.raynal@bootlin.com, Richard@desktop-tit0j8o.localdomain, Weinberger@desktop-tit0j8o.localdomain, richard@nod.at, Vignesh@desktop-tit0j8o.localdomain, Raghavendra@desktop-tit0j8o.localdomain, vigneshr@ti.com, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Markus Stockhausen , naseefkm@gmail.com Subject: [PATCH v2] mtd: nand: realtek-ecc: relax OOB size check to minimum Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The ECC engine strictly validates that flash OOB size equals exactly 64 bytes. However, some NAND chips have a larger physical OOB while vendor firmware only uses the first 64 bytes for the ECC layout. For example the Macronix MX35LF1G24AD found in the Netlink HG323DAC has 128 byte physical OOB but vendor firmware only uses the first 64 bytes (24 bytes free + 40 bytes BCH6 parity), leaving bytes 64-127 unused. Since the engine only operates on the first 64 bytes of OOB regardless of the physical size, change the check from exact match to minimum size. Flash with OOB >=3D 64 bytes works correctly with the engine's 64-byte layout. Suggested-by: Markus Stockhausen Signed-off-by: Ahmed Naseef --- On the Netlink HG323DAC with the Macronix MX35LF1G24AD (ID: 0xc2, 0x14), the Realtek ECC engine probe fails with: spi-nand spi0.0: Macronix SPI NAND was found. spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size:= 128 rtl-nand-ecc-engine 1801a600.ecc: only flash geometry data=3D2048, oob=3D= 64 supported nand: No suitable ECC configuration spi-nand spi0.0: probe with driver spi-nand failed with error -22 The chip has 128 bytes of physical OOB but the OEM firmware only uses 64 bytes (24 free + 40 BCH6 parity). The OEM bootlog confirms: nand: device found, Manufacturer ID: 0xc2, Chip ID: 0x14 nand: Macronix nand: 128MiB, SLC, page size: 2048, OOB size: 64 The rtl9607c GPL sources have no specific entry for chip ID 0x14 in the Macronix SPI NAND table and fall back to the default 64-byte spare configuration with BCH6 ECC. I verified this by booting an OpenWrt initramfs with the ECC engine disabled and inspecting raw OOB via nanddump --noecc --oob. Both the env and kernel partitions confirm the OEM layout uses only the first 64 bytes: - OOB[0:23]: 24 bytes free (4 steps x 6 bytes) - OOB[24:63]: 40 bytes BCH6 parity (4 steps x 10 bytes) - OOB[64:127]: unused (all 0xFF) This matches the engine's expected format exactly. Since the engine only operates on the first 64 bytes, the relaxation from exact match to minimum size is safe for any flash with OOB >=3D 64. Changes in v2: - Reorder Suggested-by before Signed-off-by - Update driver comment per Markus's review drivers/mtd/nand/ecc-realtek.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/mtd/nand/ecc-realtek.c b/drivers/mtd/nand/ecc-realtek.c index 0046da37e..7d003fd72 100644 --- a/drivers/mtd/nand/ecc-realtek.c +++ b/drivers/mtd/nand/ecc-realtek.c @@ -17,10 +17,12 @@ * - BCH12 : Generate 20 ECC bytes from 512 data bytes plus 6 free bytes * * It can run for arbitrary NAND flash chips with different block and OOB = sizes. Currently there - * are only two known devices in the wild that have NAND flash and make us= e of this ECC engine - * (Linksys LGS328C & LGS352C). To keep compatibility with vendor firmware= , new modes can only - * be added when new data layouts have been analyzed. For now allow BCH6 o= n flash with 2048 byte - * blocks and 64 bytes oob. + * are a few known devices in the wild that make use of this ECC engine + * (Linksys LGS328C, LGS352C & Netlink HG323DAC). To keep compatibility wi= th vendor firmware, + * new modes can only be added when new data layouts have been analyzed. F= or now allow BCH6 on + * flash with 2048 byte blocks and at least 64 bytes oob. Some vendors mak= e use of + * 128 bytes OOB NAND chips (e.g. Macronix MX35LF1G24AD) but only use BCH6= and thus the first + * 64 bytes of the OOB area. In this case the engine leaves any extra byte= s unused. * * This driver aligns with kernel ECC naming conventions. Neverthless a sh= ort notice on the * Realtek naming conventions for the different structures in the OOB area. @@ -39,7 +41,7 @@ */ =20 #define RTL_ECC_ALLOWED_PAGE_SIZE 2048 -#define RTL_ECC_ALLOWED_OOB_SIZE 64 +#define RTL_ECC_ALLOWED_MIN_OOB_SIZE 64 #define RTL_ECC_ALLOWED_STRENGTH 6 =20 #define RTL_ECC_BLOCK_SIZE 512 @@ -310,10 +312,10 @@ static int rtl_ecc_check_support(struct nand_device *= nand) struct mtd_info *mtd =3D nanddev_to_mtd(nand); struct device *dev =3D nand->ecc.engine->dev; =20 - if (mtd->oobsize !=3D RTL_ECC_ALLOWED_OOB_SIZE || + if (mtd->oobsize < RTL_ECC_ALLOWED_MIN_OOB_SIZE || mtd->writesize !=3D RTL_ECC_ALLOWED_PAGE_SIZE) { - dev_err(dev, "only flash geometry data=3D%d, oob=3D%d supported\n", - RTL_ECC_ALLOWED_PAGE_SIZE, RTL_ECC_ALLOWED_OOB_SIZE); + dev_err(dev, "only flash geometry data=3D%d, oob>=3D%d supported\n", + RTL_ECC_ALLOWED_PAGE_SIZE, RTL_ECC_ALLOWED_MIN_OOB_SIZE); return -EINVAL; } =20 --=20 2.34.1