All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ahmed Naseef <naseefkm@gmail.com>
To: miquel.raynal@bootlin.com
Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	naseefkm@gmail.com, richard@nod.at, vigneshr@ti.com
Subject: Re: [PATCH] mtd: spinand: add support for Dosilicon DS35Q1GA/DS35M1GA
Date: Tue,  9 Dec 2025 11:06:41 +0400	[thread overview]
Message-ID: <20251209070641.34589-1-naseefkm@gmail.com> (raw)
In-Reply-To: <87qzt573uo.fsf@bootlin.com>

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Ahmed Naseef <naseefkm@gmail.com>
To: miquel.raynal@bootlin.com
Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	naseefkm@gmail.com, richard@nod.at, vigneshr@ti.com
Subject: Re: [PATCH] mtd: spinand: add support for Dosilicon DS35Q1GA/DS35M1GA
Date: Tue,  9 Dec 2025 11:06:41 +0400	[thread overview]
Message-ID: <20251209070641.34589-1-naseefkm@gmail.com> (raw)
In-Reply-To: <87qzt573uo.fsf@bootlin.com>

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

  reply	other threads:[~2025-12-09  7:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-07 15:09 [PATCH] mtd: spinand: add support for Dosilicon DS35Q1GA/DS35M1GA Ahmed Naseef
2025-12-07 15:09 ` Ahmed Naseef
2025-12-08  8:52 ` Miquel Raynal
2025-12-08  8:52   ` Miquel Raynal
2025-12-09  7:06   ` Ahmed Naseef [this message]
2025-12-09  7:06     ` Ahmed Naseef
2025-12-08 13:53 ` kernel test robot
2025-12-08 13:53   ` kernel test robot
2025-12-08 19:43 ` kernel test robot
2025-12-08 19:43   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251209070641.34589-1-naseefkm@gmail.com \
    --to=naseefkm@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.