From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BC4AC77B7A for ; Tue, 30 May 2023 08:33:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229973AbjE3IdW (ORCPT ); Tue, 30 May 2023 04:33:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229539AbjE3IdQ (ORCPT ); Tue, 30 May 2023 04:33:16 -0400 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4D50A1 for ; Tue, 30 May 2023 01:33:13 -0700 (PDT) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id 960E85FD1D; Tue, 30 May 2023 11:33:11 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1685435591; bh=iah+zrTqnTbZamRlmW+Ybmqp3PDHYuh1a0WRns1ny6g=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; b=Q9sgChetLK6O5PUBi6o4WdrQycgjNOSOp0BUgs1dZVu6QrZcsrjfaZOlPDLfMLyBq cK3fw621aJrLpqH6/pGFZ8gkDrdAYgwjXDPpL/J2O57VkBmM+SJyP8T5QoGnPSjt1j lUtFFES5eCD1cG27GzVw9LUs8Ab6Qcqpjs+BfgpSG3NpqgAFcDAojwxn0PuDwn6qWL qlFLnFQWxZpjojWVjnoCpHogLAIxO7N59wOhnQEhjPyjXKADiRMuNpahU/zcrlg/2b iqSk7jAScBTXANKEdKO0D1mFgZXRrxY9gC9b977NjD/IvfEaOMjIzrlp+xBjF5/J3V IZSbUdDCgTfLg== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Tue, 30 May 2023 11:33:10 +0300 (MSK) Message-ID: <1d1cfd95-d0ee-e6de-d3d9-acf6defde661@sberdevices.ru> Date: Tue, 30 May 2023 11:28:33 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v4 2/5] mtd: rawnand: meson: move OOB to non-protected ECC area Content-Language: en-US To: Miquel Raynal CC: Liang Yang , Richard Weinberger , Vignesh Raghavendra , Neil Armstrong , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , Yixun Lan , Jianxin Pan , , , , , , References: <20230515094440.3552094-1-AVKrasnov@sberdevices.ru> <20230515094440.3552094-3-AVKrasnov@sberdevices.ru> <20230522173334.7aa6f917@xps-13> <20230526190347.6e34a2be@xps-13> <20230530094420.06281ab5@xps-13> <1f4c90c4-e436-c53f-bb6f-416db374ae52@sberdevices.ru> <20230530102143.6b2a199a@xps-13> From: Arseniy Krasnov In-Reply-To: <20230530102143.6b2a199a@xps-13> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH01.sberdevices.ru (172.16.1.4) To S-MS-EXCH01.sberdevices.ru (172.16.1.4) X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2023/05/30 04:52:00 #21374971 X-KSMG-AntiVirus-Status: Clean, skipped Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30.05.2023 11:21, Miquel Raynal wrote: > Hi Arseniy, > > avkrasnov@sberdevices.ru wrote on Tue, 30 May 2023 11:09:10 +0300: > >> Hi Miquel, >> >> On 30.05.2023 10:44, Miquel Raynal wrote: >>> Hi Arseniy, >>> >>>>>>>> -static void meson_nfc_get_user_byte(struct nand_chip *nand, u8 *oob_buf) >>>>>>>> -{ >>>>>>>> - struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand); >>>>>>>> - __le64 *info; >>>>>>>> - int i, count; >>>>>>>> + int i; >>>>>>>> >>>>>>>> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { >>>>>>>> + for (i = 0; i < nand->ecc.steps; i++) { >>>>>>>> info = &meson_chip->info_buf[i]; >>>>>>>> - oob_buf[count] = *info; >>>>>>>> - oob_buf[count + 1] = *info >> 8; >>>>>>>> + /* Always ignore user bytes programming. */ >>>>>>> >>>>>>> Why? >>>>>> >>>>>> I think comment message is wrong a little bit. Here "user bytes" are >>>>>> user bytes protected by ECC (e.g. location of these bytes differs from new >>>>>> OOB layout introduced by this patch). During page write this hardware >>>>>> always writes these bytes along with data. But, new OOB layout always ignores >>>>>> these 4 bytes, so set them to 0xFF always. >>>>> >>>>> When performing page reads/writes, you need to take the data as it's >>>>> been provided. You may move the data around in the buffer provided to >>>>> the controller, so that it get the ECC data at the right location, and >>>>> you need of course to reorganize the data when reading as well, so that >>>>> the user sees XkiB of data + YB of OOB. That's all you need to do in >>>>> these helpers. >>>>> >>>> >>>> I think there is some misunderstanding about these "user bytes" above: there are 4 >>>> bytes which this NAND controller always writes to page in ECC mode - it was free OOB >>>> bytes covered by ECC. Controller grabs values from DMA buffer (second DMA buffer which >>>> doesn't contains page data) and writes it along with data and ECC codes. Idea of this >>>> change is to always suppress this write by setting them to 0xFF (may be there is some >>>> command option to not write it, but I don't have doc), because all of them (4 bytes) >>>> become unavailable to reader/writer. >>> >>> At the NAND controller level, I would rather avoid doing things like >>> that. >>> >>> I believe you can just update the ooblayout so that protected OOB bytes >>> are not exposed to the user as free bytes. Then your buffers should >>> already contain 0xffffff at the problematic location. >> >> So Your idea is to continue fill DMA buffer (for these 4 bytes) from provided OOB buffer, >> relying on that as these bytes are unused, they will be 0xFF in OOB buffer so we get the same result? > > Yes. > > The problem you face is due to jffs2 using free OOB bytes to store some > data. If this data is in the protected area -> BOOM. > > If another application wants to use all the bytes and writes them all > in the same PROGRAM operation it's fine. > > Jffs2 accesses the free area through the OOB layouts only, so just > tweaking the OOB layouts should work. I see, I'll try this. Thanks, Arseniy > > Thanks, > Miquèl