Message-ID: <20230426073632.3905682-1-AVKrasnov@sberdevices.ru>
Date:   Wed, 26 Apr 2023 10:36:26 +0300
From:   Arseniy Krasnov <AVKrasnov@...rdevices.ru>
To:     Liang Yang <liang.yang@...ogic.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Kevin Hilman <khilman@...libre.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Jianxin Pan <jianxin.pan@...ogic.com>,
        Yixun Lan <yixun.lan@...ogic.com>
CC:     <oxffffaa@...il.com>, <kernel@...rdevices.ru>,
        Arseniy Krasnov <AVKrasnov@...rdevices.ru>,
        <linux-mtd@...ts.infradead.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-amlogic@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: [PATCH v2 0/5] refactoring and fix for Meson NAND

Hello,

this patchset does several things:

1) It fixes unstable behaviour of Meson driver, for example random ECC
   errors during reads. It is done by changing command sequence to access
   NAND controller. Source of this update is old vendor's driver.

2) It changes OOB layout by moving it out of ECC area. Current OOB data
   is 4 bytes (2 x 2 user bytes) under ECC engine. Here is how OOB looks
   in the current implementation:

   [ 2B user bytes ][     14B ECC codes    ]
   [ 2B user bytes ][     14B ECC codes    ]
   [ 16B unused area, not protected by ECC ]
   [ 16B unused area, not protected by ECC ]

   All 4 user bytes are protected by ECC. This patch changes OOB layout
   in this way:

   [ 2B unused area ][    14B ECC codes    ]
   [ 2B unused area ][    14B ECC codes    ]
   [  16B OOB area, not protected by ECC   ]
   [  16B OOB area, not protected by ECC   ]

   Now OOB is 32 bytes instead of 4 bytes and not protected by ECC.
   Origin of this layout comes from problem with JFFS2. It uses OOB for
   cleanmarkers. Each cleanmarker is 4 bytes and written by JFFS2 driver.
   We have two ways to write this data to OOB (e.g. user bytes):

   1) ECC mode. In this case it will be ECC covered user bytes, e.g.
      writing this bytes will update ECC codes. Problem fires, when
      JFFS2 tries to write this page later - this write makes controller
      to update ECC codes again, but it is impossible to do it correctly,
      because we can't update bits from 0 to 1 (only from 1 to 0).

   2) Raw mode. In this case ECC codes won't be updated. But later, it
      will be impossible to read this page in ECC mode, because we have
      some user bytes, but ECC codes are missed.

   So let's move OOB out of ECC area. In this case we can read/write OOB
   separately in raw mode and at the same time work with data in ECC
   mode. JFFS2 is happy now. User bytes are untouched - all of them
   are ignored during non-OOB access.

   Also this patch changes size of OOB data during read. Now whole OOB
   is read (including unused user bytes, ECC codes and OOB data itself).

   I've tested this with mount/unmount/read/write cases for JFFS2 and
   nanddump/nandwrite utlities on AXG family (A113X SoC).

3) Renames device tree node's name for chip selection from "reg" to
   "cs". See commit message.

4) Checks buffer length on accesses to NAND controller.

5) Removes useless bitwise OR with zeroes.

Link to v1:
https://lore.kernel.org/linux-mtd/20230412061700.1492474-1-AVKrasnov@sberdevices.ru/

Arseniy Krasnov (5):
  mtd: rawnand: meson: fix NAND access for read/write
  mtd: rawnand: meson: move OOB to non-protected ECC area
  mtd: rawnand: meson: check buffer length
  mtd: rawnand: meson: remove unneeded bitwise OR with zeroes
  mtd: rawnand: meson: rename node for chip select

 drivers/mtd/nand/raw/meson_nand.c | 406 +++++++++++++++++++++++++-----
 1 file changed, 347 insertions(+), 59 deletions(-)

-- 
2.35.0

Powered by blists - more mailing lists