public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Frieder Schrempf <frieder.schrempf@kontron.de>
Cc: Martin Kurbanov <mmkurbanov@sberdevices.ru>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	kernel@sberdevices.ru
Subject: Re: [PATCH v1] mtd: spinand: micron: correct parameters
Date: Thu, 17 Aug 2023 09:53:54 +0200	[thread overview]
Message-ID: <20230817095354.3df2f7f9@xps-13> (raw)
In-Reply-To: <53a4fe26-3a6a-47ce-8532-be60da674aca@kontron.de>

Hi Frieder,

frieder.schrempf@kontron.de wrote on Wed, 16 Aug 2023 17:35:56 +0200:

> On 16.08.23 17:28, Martin Kurbanov wrote:
> > Hi Frieder.
> > 
> > On 16.08.2023 10:21, Frieder Schrempf wrote:  
> >> I'm okay with 1. and with adjusting region->offset to 4. But I don't
> >> really get why we want to restrict the free oob data to the
> >> non-ECC-protected area only. Is this specific to Micron? Other SPI NAND
> >> drivers also spread the free area over both, the ECC-protected and the
> >> non-protected bytes. Why do it differently here?  
> > 
> > We encountered a problem with the JFFS2 file system: JFFS2 marks erased
> > blocks with a marker to avoid re-erasing them. To do this, it writes
> > a special marker (cleanmarker) in the free OOB area. And if this OOB
> > area is protected by ECC, the ECC will be written. However, during
> > the next write to the main area of the same block, the ECC will be
> > incorrect because it's necessary to program both the main area and
> > the OOB area at one programming time, so that the ECC parity code can
> > be calculated properly. Other SPI NAND flash also susceptible to
> > this problem.  
> 
> Thanks for the explanation. As this is a generic issue, we need to fix
> it in the core and not in the Micron driver.

It's not the first time we face this issue and the first approach we
used was to "fix" the OOB layout to include all free bytes (not only
protected bytes), which had the nice side-effect of allowing to write
the cleanmarker in an ECC-free area and allow that chip to be used with
JFFS2. This is indeed not a proper solution and I agree we should have
a system-wide solution.

> Also I wonder if JFFS2 should instead write the cleanmarker with ECC
> being turned of explicitly.

The real question is, why would you still want to use JFFS2 on
SPI-NAND? UBI is meant for that. JFFS2 was designed with NORs in mind,
it can be used on small NAND chips because UBI is a bit glutton wrt,
but I doubt we still have "small" SPI-NANDs on the market which require
JFFS2 anymore. Do we?

Anyhow, if people want JFFS2 on NANDs, I agree we should maybe change
how JFFS2 works and force raw accesses when it comes to writing the
cleanmarker, because there is no knowledge of what is ECC protected or
not in the current OOB layouts. I however have no idea of the possible
side-effects, I've never looked into JFFS2 so deeply.

> I don't know enough about NAND and JFFS2 to point out a correct fix, but
> I hope Miquel and Richard have some ideas.

Thanks,
Miquèl

  reply	other threads:[~2023-08-17  7:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-15 16:10 [PATCH v1] mtd: spinand: micron: correct parameters Martin Kurbanov
2023-08-16  7:21 ` Frieder Schrempf
2023-08-16 15:28   ` Martin Kurbanov
2023-08-16 15:35     ` Frieder Schrempf
2023-08-17  7:53       ` Miquel Raynal [this message]
2023-08-21 17:36         ` Martin Kurbanov

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=20230817095354.3df2f7f9@xps-13 \
    --to=miquel.raynal@bootlin.com \
    --cc=frieder.schrempf@kontron.de \
    --cc=kernel@sberdevices.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mmkurbanov@sberdevices.ru \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox