Message ID | 20231109053953.3863664-1-avkrasnov@salutedevices.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b129:0:b0:403:3b70:6f57 with SMTP id q9csp235776vqs; Wed, 8 Nov 2023 21:48:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IGAT8tZrtwA4Mztwv4ba0l5EsgpbHtZuAtFcU8d0loOYxp97duH/ibVDrl1WUlTRjXPADpk X-Received: by 2002:a17:903:4304:b0:1cc:3004:750c with SMTP id jz4-20020a170903430400b001cc3004750cmr8824933plb.20.1699508915652; Wed, 08 Nov 2023 21:48:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699508915; cv=none; d=google.com; s=arc-20160816; b=Wx3tMdKfY7CPQubu94UJCffL35MCMSecE2mpL4+/H7F/NJJaeCVhnlHcW0llS7cR4Y 7W0c5GMyUPMkhj7p/UiMtGvWG5AOP9RpTeJP4Semn1fS80nOzLQ19okwjmqHUO1Dxsl8 1UNBZ/AgUiaDRp9nH8JdlIz8xcwJoHvJTQBYrTjJvdklT4RY0iE/JElJ1sOfLJbe4T5B nQSaA03sY5flMcf+X1xiKb02JsQNYeYdaA5OFVqdISKa2ljgWo3E2Pws1MiVG3uPX5Vr PfH9ne+ChDTZfq+QnzThm2tPHbrAaT76VkYrzRD2tu68G8ENLN59hdRm0lKZj7izyGch NoRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature:dkim-filter; bh=iEPGOwwFpiz4fNsEZ5A9kxrGYqz51ztVWpwbPLPuTaU=; fh=vKhyrKlD93RV6i466L67S2aXBM1Y21d1ZLxy7HAQjS0=; b=b9eZWwm6H5lsvUcEQM2sUc/exZrSPLtaYy2Luvn2gOs3TwbzNoNrn9ql9kCZTz1rua 9zZ5hWHEdmESQu4Kq8wDatSTDCzTAzcnjYBlwGOL+vRG3KD/wcx9J9FuhdSpmSTPhzlY IE/Sh14diis5XXEBKz+ZhNFc57bIt+vQNz/NOR32DmYmc1y83wf4zCgTy8HnhcbWlQ3P PjRjfwAIX5rCUP8RrQhgc4J8Zanxdx7FZ+JQLTvYzsAlIeo20pASjF7OaL8ub1Xki2L4 R4sX2vtJ7oUq6EDSKYZsj8XdnTU9WDwLmqB7Ylqq1CF6WKASocCxNzVeLAfVmF2fvRWI bkIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@salutedevices.com header.s=mail header.b=Gi+rME1y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=salutedevices.com Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id h70-20020a638349000000b005bdbeb537cfsi5535064pge.186.2023.11.08.21.48.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Nov 2023 21:48:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@salutedevices.com header.s=mail header.b=Gi+rME1y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=salutedevices.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 56C1981DDBF2; Wed, 8 Nov 2023 21:48:33 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232465AbjKIFsT (ORCPT <rfc822;jaysivo@gmail.com> + 32 others); Thu, 9 Nov 2023 00:48:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232841AbjKIFsE (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 9 Nov 2023 00:48:04 -0500 Received: from mx1.sberdevices.ru (mx1.sberdevices.ru [37.18.73.165]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A55A273C for <linux-kernel@vger.kernel.org>; Wed, 8 Nov 2023 21:47:52 -0800 (PST) Received: from p-infra-ksmg-sc-msk01 (localhost [127.0.0.1]) by mx1.sberdevices.ru (Postfix) with ESMTP id 2471910003B; Thu, 9 Nov 2023 08:47:51 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.sberdevices.ru 2471910003B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salutedevices.com; s=mail; t=1699508871; bh=iEPGOwwFpiz4fNsEZ5A9kxrGYqz51ztVWpwbPLPuTaU=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From; b=Gi+rME1yqP8TWRgKUOiVsTNmRCx+ucxbPYrXjc8BCv4a8sKmlvxZosiAsSjC0RwVU e8L3owLEYPUOm7t/xB13m17l6ihEetWUZRKFYdTpwMT9Ob4vHWBTq/gNCIjf9+5wkt gXvF3tFlUTewjFTjCqciP2Fwd0s9odbL4ydYSxrYs1+j2E5rE3xbjbTQiIijicmLm9 NPXNYg6U+cZqgAlTqUirtmZwWd+oFY5SbNNsaBJFxxrfwcgkasjnUbygklQMDzsXqd GvqZ5yleCBHGBXrWrLAp1bILGgwI3Op9iVjcRH2JF4m3gP+rAV6yknEKHCtEtsAjn6 IDLfeyyMNpJjg== Received: from p-i-exch-sc-m01.sberdevices.ru (p-i-exch-sc-m01.sberdevices.ru [172.16.192.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sberdevices.ru (Postfix) with ESMTPS; Thu, 9 Nov 2023 08:47:50 +0300 (MSK) Received: from localhost.localdomain (100.64.160.123) by p-i-exch-sc-m01.sberdevices.ru (172.16.192.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.37; Thu, 9 Nov 2023 08:47:50 +0300 From: Arseniy Krasnov <avkrasnov@salutedevices.com> To: Liang Yang <liang.yang@amlogic.com>, Miquel Raynal <miquel.raynal@bootlin.com>, Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Neil Armstrong <neil.armstrong@linaro.org>, Kevin Hilman <khilman@baylibre.com>, Jerome Brunet <jbrunet@baylibre.com>, Martin Blumenstingl <martin.blumenstingl@googlemail.com> CC: <oxffffaa@gmail.com>, <kernel@sberdevices.ru>, Arseniy Krasnov <avkrasnov@salutedevices.com>, <linux-mtd@lists.infradead.org>, <linux-arm-kernel@lists.infradead.org>, <linux-amlogic@lists.infradead.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH v1] mtd: rawnand: meson: handle OOB buffer according OOB layout Date: Thu, 9 Nov 2023 08:39:53 +0300 Message-ID: <20231109053953.3863664-1-avkrasnov@salutedevices.com> X-Mailer: git-send-email 2.35.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [100.64.160.123] X-ClientProxiedBy: p-i-exch-sc-m01.sberdevices.ru (172.16.192.107) To p-i-exch-sc-m01.sberdevices.ru (172.16.192.107) X-KSMG-Rule-ID: 10 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Lua-Profiles: 181222 [Nov 09 2023] X-KSMG-AntiSpam-Version: 6.0.0.2 X-KSMG-AntiSpam-Envelope-From: avkrasnov@salutedevices.com X-KSMG-AntiSpam-Rate: 0 X-KSMG-AntiSpam-Status: not_detected X-KSMG-AntiSpam-Method: none X-KSMG-AntiSpam-Auth: dkim=none X-KSMG-AntiSpam-Info: LuaCore: 543 543 1e3516af5cdd92079dfeb0e292c8747a62cb1ee4, {Tracking_from_domain_doesnt_match_to}, salutedevices.com:7.1.1;d41d8cd98f00b204e9800998ecf8427e.com:7.1.1;100.64.160.123:7.1.2;p-i-exch-sc-m01.sberdevices.ru:5.0.1,7.1.1;127.0.0.199:7.1.2, FromAlignment: s, ApMailHostAddress: 100.64.160.123 X-MS-Exchange-Organization-SCL: -1 X-KSMG-AntiSpam-Interceptor-Info: scan successful X-KSMG-AntiPhishing: Clean X-KSMG-LinksScanning: Clean X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.0.1.6960, bases: 2023/11/09 02:48:00 #22434346 X-KSMG-AntiVirus-Status: Clean, skipped Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Wed, 08 Nov 2023 21:48:33 -0800 (PST) X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782064260268042830 X-GMAIL-MSGID: 1782064260268042830 |
Series |
[v1] mtd: rawnand: meson: handle OOB buffer according OOB layout
|
|
Commit Message
Arseniy Krasnov
Nov. 9, 2023, 5:39 a.m. UTC
In case of MTD_OPS_AUTO_OOB mode, MTD/NAND layer fills/reads OOB buffer
according current OOB layout so we need to follow it in the driver.
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
---
drivers/mtd/nand/raw/meson_nand.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Hi! On Thu, 2023-11-09 at 08:39 +0300, Arseniy Krasnov wrote: > In case of MTD_OPS_AUTO_OOB mode, MTD/NAND layer fills/reads OOB buffer > according current OOB layout so we need to follow it in the driver. > > Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> > --- > drivers/mtd/nand/raw/meson_nand.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c > index 561d46d860b7..0d4d358152d7 100644 > --- a/drivers/mtd/nand/raw/meson_nand.c > +++ b/drivers/mtd/nand/raw/meson_nand.c > @@ -510,7 +510,7 @@ static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf) > __le64 *info; > int i, count; > > - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { > + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { > info = &meson_chip->info_buf[i]; > *info |= oob_buf[count]; > *info |= oob_buf[count + 1] << 8; Seems something wrong with your logic here. I think this code should most likely look like this: for (i = 0, count = 0; i < nand->ecc.steps; i++, count += nand->ecc.bytes) { info = &meson_chip->info_buf[i]; *info |= oob_buf[count]; if (nand->ecc.bytes > 1) *info |= oob_buf[count + 1] << 8; } > @@ -523,7 +523,7 @@ static void meson_nfc_get_user_byte(struct nand_chip *nand, u8 *oob_buf) > __le64 *info; > int i, count; > > - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { > + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { > info = &meson_chip->info_buf[i]; > oob_buf[count] = *info; > oob_buf[count + 1] = *info >> 8; And there: for (i = 0, count = 0; i < nand->ecc.steps; i++, count += nand->ecc.bytes) { info = &meson_chip->info_buf[i]; oob_buf[count] = *info; if (nand->ecc.bytes > 1) oob_buf[count + 1] = *info >> 8; } This is more similar to the behavior of similar functions in the proprietary U-Boot. -- Viacheslav Bocharov
Hello, thanks for review! On 09.11.2023 11:06, Viacheslav Bocharov wrote: > Hi! > > On Thu, 2023-11-09 at 08:39 +0300, Arseniy Krasnov wrote: >> In case of MTD_OPS_AUTO_OOB mode, MTD/NAND layer fills/reads OOB buffer >> according current OOB layout so we need to follow it in the driver. >> >> Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> >> --- >> drivers/mtd/nand/raw/meson_nand.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c >> index 561d46d860b7..0d4d358152d7 100644 >> --- a/drivers/mtd/nand/raw/meson_nand.c >> +++ b/drivers/mtd/nand/raw/meson_nand.c >> @@ -510,7 +510,7 @@ static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf) >> __le64 *info; >> int i, count; >> >> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { >> + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { >> info = &meson_chip->info_buf[i]; >> *info |= oob_buf[count]; >> *info |= oob_buf[count + 1] << 8; > Seems something wrong with your logic here. > I think this code should most likely look like this: > > for (i = 0, count = 0; i < nand->ecc.steps; i++, count += nand->ecc.bytes) { > info = &meson_chip->info_buf[i]; > *info |= oob_buf[count]; > if (nand->ecc.bytes > 1) > *info |= oob_buf[count + 1] << 8; > } For 64 bytes OOB and 512 bytes ECC this driver reports free areas as: AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB where AA is free byte(user byte), BB - ECC codes. So to access user bytes we need bytes 0,1,16,17,32,33,48,49. nand->ecc.bytes == 14, so 'count' is increased at 16 every iteration, so i guess this is correct. WDYT? Thanks, Arseniy > > >> @@ -523,7 +523,7 @@ static void meson_nfc_get_user_byte(struct nand_chip *nand, u8 *oob_buf) >> __le64 *info; >> int i, count; >> >> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { >> + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { >> info = &meson_chip->info_buf[i]; >> oob_buf[count] = *info; >> oob_buf[count + 1] = *info >> 8; > And there: > > for (i = 0, count = 0; i < nand->ecc.steps; i++, count += nand->ecc.bytes) { > info = &meson_chip->info_buf[i]; > oob_buf[count] = *info; > if (nand->ecc.bytes > 1) > oob_buf[count + 1] = *info >> 8; > } > > > This is more similar to the behavior of similar functions in the proprietary U-Boot. > > -- > Viacheslav Bocharov >
Hello all, 2 weeks from 9.11, please ping Thanks, Arseniy On 09.11.2023 12:09, Arseniy Krasnov wrote: > Hello, thanks for review! > > On 09.11.2023 11:06, Viacheslav Bocharov wrote: >> Hi! >> >> On Thu, 2023-11-09 at 08:39 +0300, Arseniy Krasnov wrote: >>> In case of MTD_OPS_AUTO_OOB mode, MTD/NAND layer fills/reads OOB buffer >>> according current OOB layout so we need to follow it in the driver. >>> >>> Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> >>> --- >>> drivers/mtd/nand/raw/meson_nand.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c >>> index 561d46d860b7..0d4d358152d7 100644 >>> --- a/drivers/mtd/nand/raw/meson_nand.c >>> +++ b/drivers/mtd/nand/raw/meson_nand.c >>> @@ -510,7 +510,7 @@ static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf) >>> __le64 *info; >>> int i, count; >>> >>> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { >>> + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { >>> info = &meson_chip->info_buf[i]; >>> *info |= oob_buf[count]; >>> *info |= oob_buf[count + 1] << 8; >> Seems something wrong with your logic here. >> I think this code should most likely look like this: >> >> for (i = 0, count = 0; i < nand->ecc.steps; i++, count += nand->ecc.bytes) { >> info = &meson_chip->info_buf[i]; >> *info |= oob_buf[count]; >> if (nand->ecc.bytes > 1) >> *info |= oob_buf[count + 1] << 8; >> } > > For 64 bytes OOB and 512 bytes ECC this driver reports free areas as: > > AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB > AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB > AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB > AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB > > where AA is free byte(user byte), BB - ECC codes. So to access user bytes > we need bytes 0,1,16,17,32,33,48,49. nand->ecc.bytes == 14, so 'count' is > increased at 16 every iteration, so i guess this is correct. > > WDYT? > > Thanks, Arseniy > >> >> >>> @@ -523,7 +523,7 @@ static void meson_nfc_get_user_byte(struct nand_chip *nand, u8 *oob_buf) >>> __le64 *info; >>> int i, count; >>> >>> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { >>> + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { >>> info = &meson_chip->info_buf[i]; >>> oob_buf[count] = *info; >>> oob_buf[count + 1] = *info >> 8; >> And there: >> >> for (i = 0, count = 0; i < nand->ecc.steps; i++, count += nand->ecc.bytes) { >> info = &meson_chip->info_buf[i]; >> oob_buf[count] = *info; >> if (nand->ecc.bytes > 1) >> oob_buf[count + 1] = *info >> 8; >> } >> >> >> This is more similar to the behavior of similar functions in the proprietary U-Boot. >> >> -- >> Viacheslav Bocharov >>
Hi Arseniy, avkrasnov@salutedevices.com wrote on Fri, 24 Nov 2023 10:50:54 +0300: > Hello all, 2 weeks from 9.11, please ping I'm waiting for Viacheslav. > > Thanks, Arseniy > > > On 09.11.2023 12:09, Arseniy Krasnov wrote: > > Hello, thanks for review! > > > > On 09.11.2023 11:06, Viacheslav Bocharov wrote: > >> Hi! > >> > >> On Thu, 2023-11-09 at 08:39 +0300, Arseniy Krasnov wrote: > >>> In case of MTD_OPS_AUTO_OOB mode, MTD/NAND layer fills/reads OOB buffer > >>> according current OOB layout so we need to follow it in the driver. > >>> > >>> Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> > >>> --- > >>> drivers/mtd/nand/raw/meson_nand.c | 4 ++-- > >>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c > >>> index 561d46d860b7..0d4d358152d7 100644 > >>> --- a/drivers/mtd/nand/raw/meson_nand.c > >>> +++ b/drivers/mtd/nand/raw/meson_nand.c > >>> @@ -510,7 +510,7 @@ static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf) > >>> __le64 *info; > >>> int i, count; > >>> > >>> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { > >>> + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { > >>> info = &meson_chip->info_buf[i]; > >>> *info |= oob_buf[count]; > >>> *info |= oob_buf[count + 1] << 8; > >> Seems something wrong with your logic here. > >> I think this code should most likely look like this: > >> > >> for (i = 0, count = 0; i < nand->ecc.steps; i++, count += nand->ecc.bytes) { > >> info = &meson_chip->info_buf[i]; > >> *info |= oob_buf[count]; > >> if (nand->ecc.bytes > 1) > >> *info |= oob_buf[count + 1] << 8; > >> } > > > > For 64 bytes OOB and 512 bytes ECC this driver reports free areas as: > > > > AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB > > AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB > > AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB > > AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB > > > > where AA is free byte(user byte), BB - ECC codes. So to access user bytes > > we need bytes 0,1,16,17,32,33,48,49. nand->ecc.bytes == 14, so 'count' is > > increased at 16 every iteration, so i guess this is correct. > > > > WDYT? > > > > Thanks, Arseniy > > > >> > >> > >>> @@ -523,7 +523,7 @@ static void meson_nfc_get_user_byte(struct nand_chip *nand, u8 *oob_buf) > >>> __le64 *info; > >>> int i, count; > >>> > >>> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { > >>> + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { > >>> info = &meson_chip->info_buf[i]; > >>> oob_buf[count] = *info; > >>> oob_buf[count + 1] = *info >> 8; > >> And there: > >> > >> for (i = 0, count = 0; i < nand->ecc.steps; i++, count += nand->ecc.bytes) { > >> info = &meson_chip->info_buf[i]; > >> oob_buf[count] = *info; > >> if (nand->ecc.bytes > 1) > >> oob_buf[count + 1] = *info >> 8; > >> } > >> > >> > >> This is more similar to the behavior of similar functions in the proprietary U-Boot. > >> > >> -- > >> Viacheslav Bocharov > >> Thanks, Miquèl
Hi, Miquel! 24/11/2023 12.06, Miquel Raynal wrote: > Hi Arseniy, > > avkrasnov@salutedevices.com wrote on Fri, 24 Nov 2023 10:50:54 +0300: > >> Hello all, 2 weeks from 9.11, please ping > > I'm waiting for Viacheslav. We discussed this update with Arseniy. My suggestion was based on the difference in patch from the algorithms used in amlogic u-boot. Arseniy claims that everything works for them. Unfortunately, I don't have the devices available to test this. > >> >> Thanks, Arseniy >> >> >> On 09.11.2023 12:09, Arseniy Krasnov wrote: >>> Hello, thanks for review! >>> >>> On 09.11.2023 11:06, Viacheslav Bocharov wrote: >>>> Hi! >>>> >>>> On Thu, 2023-11-09 at 08:39 +0300, Arseniy Krasnov wrote: >>>>> In case of MTD_OPS_AUTO_OOB mode, MTD/NAND layer fills/reads OOB buffer >>>>> according current OOB layout so we need to follow it in the driver. >>>>> >>>>> Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> >>>>> --- >>>>> drivers/mtd/nand/raw/meson_nand.c | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c >>>>> index 561d46d860b7..0d4d358152d7 100644 >>>>> --- a/drivers/mtd/nand/raw/meson_nand.c >>>>> +++ b/drivers/mtd/nand/raw/meson_nand.c >>>>> @@ -510,7 +510,7 @@ static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf) >>>>> __le64 *info; >>>>> int i, count; >>>>> >>>>> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { >>>>> + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { >>>>> info = &meson_chip->info_buf[i]; >>>>> *info |= oob_buf[count]; >>>>> *info |= oob_buf[count + 1] << 8; >>>> Seems something wrong with your logic here. >>>> I think this code should most likely look like this: >>>> >>>> for (i = 0, count = 0; i < nand->ecc.steps; i++, count += nand->ecc.bytes) { >>>> info = &meson_chip->info_buf[i]; >>>> *info |= oob_buf[count]; >>>> if (nand->ecc.bytes > 1) >>>> *info |= oob_buf[count + 1] << 8; >>>> } >>> >>> For 64 bytes OOB and 512 bytes ECC this driver reports free areas as: >>> >>> AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB >>> AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB >>> AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB >>> AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB >>> >>> where AA is free byte(user byte), BB - ECC codes. So to access user bytes >>> we need bytes 0,1,16,17,32,33,48,49. nand->ecc.bytes == 14, so 'count' is >>> increased at 16 every iteration, so i guess this is correct. >>> >>> WDYT? >>> >>> Thanks, Arseniy >>> >>>> >>>> >>>>> @@ -523,7 +523,7 @@ static void meson_nfc_get_user_byte(struct nand_chip *nand, u8 *oob_buf) >>>>> __le64 *info; >>>>> int i, count; >>>>> >>>>> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { >>>>> + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { >>>>> info = &meson_chip->info_buf[i]; >>>>> oob_buf[count] = *info; >>>>> oob_buf[count + 1] = *info >> 8; >>>> And there: >>>> >>>> for (i = 0, count = 0; i < nand->ecc.steps; i++, count += nand->ecc.bytes) { >>>> info = &meson_chip->info_buf[i]; >>>> oob_buf[count] = *info; >>>> if (nand->ecc.bytes > 1) >>>> oob_buf[count + 1] = *info >> 8; >>>> } >>>> >>>> >>>> This is more similar to the behavior of similar functions in the proprietary U-Boot. >>>> >>>> -- >>>> Viacheslav Bocharov >>>> > > > Thanks, > Miquèl -- Viacheslav Bocharov
On Thu, 2023-11-09 at 05:39:53 UTC, Arseniy Krasnov wrote: > In case of MTD_OPS_AUTO_OOB mode, MTD/NAND layer fills/reads OOB buffer > according current OOB layout so we need to follow it in the driver. > > Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks. Miquel
diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c index 561d46d860b7..0d4d358152d7 100644 --- a/drivers/mtd/nand/raw/meson_nand.c +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -510,7 +510,7 @@ static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf) __le64 *info; int i, count; - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { info = &meson_chip->info_buf[i]; *info |= oob_buf[count]; *info |= oob_buf[count + 1] << 8; @@ -523,7 +523,7 @@ static void meson_nfc_get_user_byte(struct nand_chip *nand, u8 *oob_buf) __le64 *info; int i, count; - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += 2) { + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (2 + nand->ecc.bytes)) { info = &meson_chip->info_buf[i]; oob_buf[count] = *info; oob_buf[count + 1] = *info >> 8;