From nobody Mon Feb 9 04:31:10 2026 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (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 E275D3612FE for ; Fri, 6 Feb 2026 10:59:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770375549; cv=none; b=lJpb22kZA+TLdh3ZOU+2mYozGE6nnQIIiHmixaVoipGBYLoJnR++3Jt65yB2ENeqWn8/5FAoc0UTFDH7i58wkS2SLBjE7U7Zi801pq8ECjWYPQCky6VqKDMtFaEOL9OLeMkyjxvsnt8yFyzP9zSjFA51LeykHmtXLRmoZaXW/do= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770375549; c=relaxed/simple; bh=UBH298gXx6QUj2B1eOG3b9mRJTnDWtwzr/4V6ywkYhw=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=IAGJW9BAp5FcVj5zFqce6Kkn9fEBycFB9rG7lP2j//3CuJb4R70cY03n4OZj7YC/AdJ4TfxCOLk60MBeNUyXDj9/HehOTBrjc1HunLzM4uzsOHS5R9Adw++/S9XOHjyu0rrRwnKGQ9QeCObnz0cir9Dy8PnH0dT+z75hPHWDrwo= 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=RQ74DZzA; arc=none smtp.client-ip=209.85.216.53 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="RQ74DZzA" Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-354b79a9ad5so203693a91.1 for ; Fri, 06 Feb 2026 02:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770375548; x=1770980348; 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=oQwt5IqIkOZZ+qzQveJ8TG5nKHMAOt9DhTdseZr0Ibs=; b=RQ74DZzAIZeRe0FhzXvh+Imt8UuNpP6pkkSKlH7TQ1RNL7GereIN1mEMTlq1FVDcWR r4zUvdyANQxR2opd4jupzCAI53KBZ+7egrxMcfiYY7MZ+U76KS/XDjmezVjM62ZUrLER M4kwx4th58lqkX6mYUa++9mwVqoSeVKnRVP9vayZsk3q8eNggZ9aLfke+TynJXSa26tg FiXW8BQo+x0Gos1Xf7a8UT2Mqo0rgGe1SVizytEGifOkkTA6BhLV7hjTZB1htxKZQEnb YYT2a0t+xsJrXiB2fHcHMbP5bGBGRBmqdsHMwmd2SohTiMZRjX6dnybAxy3kqQDCgRbd 0uhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770375548; x=1770980348; 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=oQwt5IqIkOZZ+qzQveJ8TG5nKHMAOt9DhTdseZr0Ibs=; b=DsK5/pd0eqDdvi+G0SuBWa3scLCF4FMELHo+k1HJOSHpOAgUVCTeSG5KQ88IjfW2Uv gObYu6lEcI3XLx+XrGVd2KCtPUZUoKjqVPDjlkLvcZVBJjabTF69iDRVtW7/yv+48phO QD/UwvT5N30Ug+uZeD/Q4c2UVRJt8ZWF1TZgtbPlmvrlNZmC6IJBaU5ALeOZS7dejy4s T59UWMNP6h35TYMZc3rIQIhnwvnc5mfxQrlXtz0ecNkJXnG8f+CJ0umVUzEJoOCJAu7u nm6geMwMZyjhYTc2MvZNf1v9lcU3iE+VnMeqYQCjfM4IDtZ41qRvG+y10f3tmYvo+Zm7 g+gg== X-Forwarded-Encrypted: i=1; AJvYcCVAKdHoIrIrVbVRxDTjyR6vmQ2A/eJY3NgftclckmUTym1+9CD/Yy2JHKGLbzf03/xOg2aSJspHFtk/pms=@vger.kernel.org X-Gm-Message-State: AOJu0Yzr3FMR6DqKKAKFpwGtGod+LoPzZziUx+TVUjGr5YEGZn55JlW1 im6KzVdXjZ19LJwl8B/TYQ3n+yt8Et+YnslKKsuuptbgu1ikUy6gcsLc X-Gm-Gg: AZuq6aLGr1PNlHcTBoMrOiBY2lEx2BACxzeANNQALUPZNRPVDoiNAQQXNuye3RLsiNY +RCDUquDTY+OXlazBInT5AyEz4wtIvGORlNpYTZN8LAOs0zCw8wSk6GNV13h2X8YLs+p+Skormz zF4PN0NJLMIQsW1PCDqBvIFBgdz03V5nuHz7UnOllwfzGMQ+ZEGJul7B9nQzh4o4pl0fgwCbzCZ U5WLLAG7yQwSSDek0TmHyw+7R8NVzktwuKs0Io13Zn53XUCX7NdkbvHkD3qcn6uRxbUTwowQzmb PVQBJUKZFAdduEmLOe1elRwt6/vnxaLYicjPo/VY91TK7A1uQdg7Q7uEuohQh/s+Ow/TyKkIpxA AkV+GJyulcnq9gchRx7IZ5S1HIEMLeb6MxzUaW9Jc+Q1lu1tuRs7JDOaPaC6W8d+YUDaA1BKYD4 wdK1Q2XnoUAsN8M5WDb2mhJZraCsPm+ZzmNGpYsDA= X-Received: by 2002:a17:90b:5746:b0:34c:6124:3616 with SMTP id 98e67ed59e1d1-354b3e460f2mr1983693a91.27.1770375548025; Fri, 06 Feb 2026 02:59:08 -0800 (PST) Received: from DESKTOP-TIT0J8O.localdomain ([49.47.198.227]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3549c0bf8bbsm5093870a91.7.2026.02.06.02.59.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Feb 2026 02:59:07 -0800 (PST) Date: Fri, 6 Feb 2026 14:57:54 +0400 From: Ahmed Naseef To: miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, markus.stockhausen@gmx.de, naseefkm@gmail.com Subject: [PATCH] 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. Signed-off-by: Ahmed Naseef Suggested-by: Markus Stockhausen --- 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. drivers/mtd/nand/ecc-realtek.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/nand/ecc-realtek.c b/drivers/mtd/nand/ecc-realtek.c index 0046da37e..9e2d15252 100644 --- a/drivers/mtd/nand/ecc-realtek.c +++ b/drivers/mtd/nand/ecc-realtek.c @@ -20,7 +20,9 @@ * 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. + * blocks and at least 64 bytes oob. Some NAND chips (e.g. Macronix MX35LF= 1G24AD) have a + * physical OOB size of 128 bytes but vendor firmware only uses the first = 64 bytes for the ECC + * layout. The engine operates on the first 64 bytes of OOB only; any extr= a bytes are 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