linux-kernel - Re: [PATCH] mtd: spinand: add support for Dosilicon DS35Q1GA/DS35M1GA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20251209070641.34589-1-naseefkm@gmail.com>
Date: Tue,  9 Dec 2025 11:06:41 +0400
From: Ahmed Naseef <naseefkm@...il.com>
To: miquel.raynal@...tlin.com
Cc: linux-kernel@...r.kernel.org,
	linux-mtd@...ts.infradead.org,
	naseefkm@...il.com,
	richard@....at,
	vigneshr@...com
Subject: Re: [PATCH] mtd: spinand: add support for Dosilicon DS35Q1GA/DS35M1GA

Hi Miquèl,

Thank you for the review. You were right about the OOB layout - it was 
incorrect.

> These macros have been renamed, please rebase at -rc1.

Done, updated in v2.

> This is strange, there is usually some spare area used for storing the
> ECC. Are you sure none of the bytes in the spare area are being smashed
> when you write them?

You were correct - the original OOB layout was wrong. I initially
misread the datasheet's "hidden spare area" phrase and assumed
ECC parity was stored internally by the chip. I've now done hardware
testing which proves otherwise.

Test procedure (on Genexis Platinum 4410)
1. Erased a block and wrote 0xAA to all 62 OOB bytes (2-63)
2. Read back the page with ECC enabled

Result:
  00000800  ff ff aa aa aa aa aa aa  e5 58 4e 86 77 75 0e f0
  00000810  aa aa aa aa aa aa aa aa  e5 58 4e 86 77 75 0e f0
  ...

The R1 regions (bytes 8-15, 24-31, 40-47, 56-63) were overwritten with
ECC parity data, while M2+M1 regions preserved the 0xAA pattern.

Corrected OOB layout (per datasheet Table 3.7):
  - 64 bytes total, 4 segments of 16 bytes each
  - Each segment: bytes 0-7 user data (M2+M1), bytes 8-15 ECC parity (R1)
  - Free: 30 bytes total (6+8+8+8, accounting for 2-byte BBM)
  - ECC: 32 bytes total (8 bytes × 4 segments)

v2 includes the corrected OOB layout with proper ECC and free region
callbacks.

Thanks,
Ahmed Naseef