Message ID | 20230627193738.19596-6-william.zhang@broadcom.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp8443268vqr; Tue, 27 Jun 2023 13:08:05 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7PzMFxSscB3+wdA0z6p0weVUD0MFGIpaR1ZFZbhVr47+DRvlVsqJV1vseWAdy7dnxpTt04 X-Received: by 2002:a17:906:3084:b0:98d:696a:531c with SMTP id 4-20020a170906308400b0098d696a531cmr11365703ejv.40.1687896485296; Tue, 27 Jun 2023 13:08:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687896485; cv=none; d=google.com; s=arc-20160816; b=QTpzZiBXuGfLQfxQbj+KbMwvrW8xpT70oxRPSUTlS1FaNs5PVOiXVnOMGp95QVyoNc 4M5tYailHIOR/2HuRXuDmmUo/RX4QjlHnrAyNWqDgn6zOotZ5VCSnWHq1mmGSN2tzJqM mvwaS9yIzwqGlw0o4SsS7qM5yK+CUEYCNMj2XMwll5pNIsvvW4lqvxKz4o2T7/JTCx6x Xj+v/tiC9KHF0NfuuBkJoYNgvdv2M14Y+xLlDydD/rJqvoKmx4jgDaSSg0O7lPAjtqUD TRqJ0UdC1xUxfRmaQSaycFgSs6km+yuMonHCJEp5cP56HvXTn7/jf+XXcvjD4aVERF9+ aqLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=BLy/S1TCUO82bkfGypenKdq41570tFEwyfGTcR0MAxc=; fh=BrMeb02/O0wx3t8cxe1CDXp3kC0urhfYBekjZ3wN7WI=; b=POGDIYCWLqaLtoo1RDIb/Bring6e6Qm2aiPCDsDLnWbir8hKPRb/NE3yZTdSt/jas1 DXpDoyeSmxtEJxpAKGAg6cM0UEqoOPbIHcsFbIGiOSWUDFdJOR0g9HAXjfO3D05BZ7S7 iCaPKWmPQZ7s0esZMqLhdPNDsCRgWYm9ELzpV+Mdqu6Q7OPU0QlvNumuW8pPP2G1f/3N bQz7BfS5TGYI0MV9FZ/TMNc9GuDpUd4tkXtOHLEqpGG1v6Z/Tdff/hVX8fdAb10G2L3E AEG6zkaJ3SAzxnksDDflAQu0yn9GHHMipMqULTM+PlGYwUqXvzFVqeI+DyAFzz+z/qR9 Bh7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b=JZUovjWB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v23-20020a17090606d700b0098e4e1279fesi3247105ejb.859.2023.06.27.13.07.41; Tue, 27 Jun 2023 13:08:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b=JZUovjWB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230195AbjF0Tiz (ORCPT <rfc822;nicolai.engesland@gmail.com> + 99 others); Tue, 27 Jun 2023 15:38:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230229AbjF0Tib (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 27 Jun 2023 15:38:31 -0400 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A02871BCF for <linux-kernel@vger.kernel.org>; Tue, 27 Jun 2023 12:38:24 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1b8303cd32aso3961735ad.2 for <linux-kernel@vger.kernel.org>; Tue, 27 Jun 2023 12:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1687894704; x=1690486704; h=mime-version:references:in-reply-to:message-id:date:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=BLy/S1TCUO82bkfGypenKdq41570tFEwyfGTcR0MAxc=; b=JZUovjWBiQ2SVPIpGIXWD01ZDby8Me+6iwhRx/KDHJvLfOBaXC3Ybpfn+wK92wiqwP O5laFY4/dfv7G+n5V6uIs9F+XjyCDtSf0YWHXuZ4bw89bFaGW5gGgPHRhgjlJGIhhDxX dbIRMW5hK0SnhMoqW6g72vOYcJWFTiANpjAm4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687894704; x=1690486704; h=mime-version:references:in-reply-to:message-id:date:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BLy/S1TCUO82bkfGypenKdq41570tFEwyfGTcR0MAxc=; b=kOY/n/nFVDcRNiafQIkjvAlqfUSPaqzVJjaO03U5/Zw4xIEae+8PpQlxR/n/TTV+U5 6tnQU5r0lDzvskI96IfvPYS3SsApXdCjRo61p0hN2UznfmzUSmrH+sTWsYe0aYbRYcqk WK1glYO2yPM6SbfXsTJiS0s6dIf2c01DrOue7GHXs3EIr9FJrszNe0AbPphIn14iWlea tAH2d0RQtQpT+Byl6sfWqNQ4ktrFWOwpw+wlcV8SsGEkwHHtXJGecM5yzdGGKCv+6zUC RAX+ZrkYKZJqfeuPWujhQ/U5tH31ayJ1KNDHjKMfw70J02I/dYmnSLG03xh1vfpU54iy fvrA== X-Gm-Message-State: AC+VfDx/tADk8qwSXiGm1f05uwq5imKpqTRRdGUcCl3yc1V0Tbkg6Na2 UCSn4Bq6QnoTOI6xHyzEcXFLjg== X-Received: by 2002:a17:903:41c2:b0:1b7:c629:f110 with SMTP id u2-20020a17090341c200b001b7c629f110mr13071912ple.63.1687894704162; Tue, 27 Jun 2023 12:38:24 -0700 (PDT) Received: from ubuntu-22.localdomain ([192.19.222.250]) by smtp.gmail.com with ESMTPSA id g7-20020a1709026b4700b001b7f40a8959sm4986919plt.76.2023.06.27.12.38.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jun 2023 12:38:23 -0700 (PDT) From: William Zhang <william.zhang@broadcom.com> To: Broadcom Kernel List <bcm-kernel-feedback-list@broadcom.com>, Linux MTD List <linux-mtd@lists.infradead.org> Cc: f.fainelli@gmail.com, rafal@milecki.pl, kursad.oney@broadcom.com, joel.peshkin@broadcom.com, computersforpeace@gmail.com, anand.gore@broadcom.com, dregan@mail.com, kamal.dasu@broadcom.com, tomer.yacoby@broadcom.com, dan.beygelman@broadcom.com, William Zhang <william.zhang@broadcom.com>, Frieder Schrempf <frieder.schrempf@kontron.de>, Miquel Raynal <miquel.raynal@bootlin.com>, linux-kernel@vger.kernel.org, Vignesh Raghavendra <vigneshr@ti.com>, Richard Weinberger <richard@nod.at>, Boris Brezillon <bbrezillon@kernel.org>, Kamal Dasu <kdasu.kdev@gmail.com> Subject: [PATCH v3 5/5] mtd: rawnand: brcmnand: Fix mtd oobsize Date: Tue, 27 Jun 2023 12:37:38 -0700 Message-Id: <20230627193738.19596-6-william.zhang@broadcom.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230627193738.19596-1-william.zhang@broadcom.com> References: <20230627193738.19596-1-william.zhang@broadcom.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000465fba05ff219c28" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769887744587595401?= X-GMAIL-MSGID: =?utf-8?q?1769887744587595401?= |
Series |
mtd: rawnand: brcmnand: driver and doc updates
|
|
Commit Message
William Zhang
June 27, 2023, 7:37 p.m. UTC
brcmnand controller can only access the flash spare area up to certain
bytes based on the ECC level. It can be less than the actual flash spare
area size. For example, for many NAND chip supporting ECC BCH-8, it has
226 bytes spare area. But controller can only uses 218 bytes. So brcmand
driver overrides the mtd oobsize with the controller's accessible spare
area size. When the nand base driver utilizes the nand_device object, it
resets the oobsize back to the actual flash spare aprea size from
nand_memory_organization structure and controller may not able to access
all the oob area as mtd advises.
This change fixes the issue by overriding the oobsize in the
nand_memory_organization structure to the controller's accessible spare
area size.
Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object")
Signed-off-by: William Zhang <william.zhang@broadcom.com>
---
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Comments
Hi William, william.zhang@broadcom.com wrote on Tue, 27 Jun 2023 12:37:38 -0700: > brcmnand controller can only access the flash spare area up to certain > bytes based on the ECC level. It can be less than the actual flash spare > area size. For example, for many NAND chip supporting ECC BCH-8, it has > 226 bytes spare area. But controller can only uses 218 bytes. So brcmand > driver overrides the mtd oobsize with the controller's accessible spare > area size. When the nand base driver utilizes the nand_device object, it > resets the oobsize back to the actual flash spare aprea size from > nand_memory_organization structure and controller may not able to access > all the oob area as mtd advises. > > This change fixes the issue by overriding the oobsize in the > nand_memory_organization structure to the controller's accessible spare > area size. I am clearly not a big fan of this solution. memorg should be and remain a read only object. Can you please find another solution? > > Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") > Signed-off-by: William Zhang <william.zhang@broadcom.com> > > --- > > Changes in v3: None > Changes in v2: None > > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > index 407bf79cbaf4..39c7f547db1f 100644 > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > @@ -2647,6 +2647,8 @@ static int brcmnand_setup_dev(struct brcmnand_host *host) > struct nand_chip *chip = &host->chip; > const struct nand_ecc_props *requirements = > nanddev_get_ecc_requirements(&chip->base); > + struct nand_memory_organization *memorg = > + nanddev_get_memorg(&chip->base); > struct brcmnand_controller *ctrl = host->ctrl; > struct brcmnand_cfg *cfg = &host->hwcfg; > char msg[128]; > @@ -2668,10 +2670,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host) > if (cfg->spare_area_size > ctrl->max_oob) > cfg->spare_area_size = ctrl->max_oob; > /* > - * Set oobsize to be consistent with controller's spare_area_size, as > - * the rest is inaccessible. > + * Set mtd and memorg oobsize to be consistent with controller's > + * spare_area_size, as the rest is inaccessible. > */ > mtd->oobsize = cfg->spare_area_size * (mtd->writesize >> FC_SHIFT); > + memorg->oobsize = mtd->oobsize; > > cfg->device_size = mtd->size; > cfg->block_size = mtd->erasesize; Thanks, Miquèl
Hi Miquel, On 07/04/2023 08:30 AM, Miquel Raynal wrote: > Hi William, > > william.zhang@broadcom.com wrote on Tue, 27 Jun 2023 12:37:38 -0700: > >> brcmnand controller can only access the flash spare area up to certain >> bytes based on the ECC level. It can be less than the actual flash spare >> area size. For example, for many NAND chip supporting ECC BCH-8, it has >> 226 bytes spare area. But controller can only uses 218 bytes. So brcmand >> driver overrides the mtd oobsize with the controller's accessible spare >> area size. When the nand base driver utilizes the nand_device object, it >> resets the oobsize back to the actual flash spare aprea size from >> nand_memory_organization structure and controller may not able to access >> all the oob area as mtd advises. >> >> This change fixes the issue by overriding the oobsize in the >> nand_memory_organization structure to the controller's accessible spare >> area size. > > I am clearly not a big fan of this solution. memorg should be and > remain a read only object. Can you please find another solution? > I was debating on this too but I don't see option because there is no other hooks after nanddev_init to set the mtd->oobsize as far as I can see and I see there were similar fixes for other controller drivers after the nand device object init was committed, for example: Fixes: 629a442cad5f ("mtd: rawnand: Fill memorg during detection") I will think through this again but I am open to any suggestion. >> >> Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") >> Signed-off-by: William Zhang <william.zhang@broadcom.com> >> >> --- >> >> Changes in v3: None >> Changes in v2: None >> >> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c >> index 407bf79cbaf4..39c7f547db1f 100644 >> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c >> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c >> @@ -2647,6 +2647,8 @@ static int brcmnand_setup_dev(struct brcmnand_host *host) >> struct nand_chip *chip = &host->chip; >> const struct nand_ecc_props *requirements = >> nanddev_get_ecc_requirements(&chip->base); >> + struct nand_memory_organization *memorg = >> + nanddev_get_memorg(&chip->base); >> struct brcmnand_controller *ctrl = host->ctrl; >> struct brcmnand_cfg *cfg = &host->hwcfg; >> char msg[128]; >> @@ -2668,10 +2670,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host) >> if (cfg->spare_area_size > ctrl->max_oob) >> cfg->spare_area_size = ctrl->max_oob; >> /* >> - * Set oobsize to be consistent with controller's spare_area_size, as >> - * the rest is inaccessible. >> + * Set mtd and memorg oobsize to be consistent with controller's >> + * spare_area_size, as the rest is inaccessible. >> */ >> mtd->oobsize = cfg->spare_area_size * (mtd->writesize >> FC_SHIFT); >> + memorg->oobsize = mtd->oobsize; >> >> cfg->device_size = mtd->size; >> cfg->block_size = mtd->erasesize; > > > Thanks, > Miquèl >
Hi William, william.zhang@broadcom.com wrote on Tue, 4 Jul 2023 17:50:28 -0700: > Hi Miquel, > > On 07/04/2023 08:30 AM, Miquel Raynal wrote: > > Hi William, > > > > william.zhang@broadcom.com wrote on Tue, 27 Jun 2023 12:37:38 -0700: > > > >> brcmnand controller can only access the flash spare area up to certain > >> bytes based on the ECC level. It can be less than the actual flash spare > >> area size. For example, for many NAND chip supporting ECC BCH-8, it has > >> 226 bytes spare area. But controller can only uses 218 bytes. So brcmand > >> driver overrides the mtd oobsize with the controller's accessible spare > >> area size. When the nand base driver utilizes the nand_device object, it > >> resets the oobsize back to the actual flash spare aprea size from > >> nand_memory_organization structure and controller may not able to access > >> all the oob area as mtd advises. > >> > >> This change fixes the issue by overriding the oobsize in the > >> nand_memory_organization structure to the controller's accessible spare > >> area size. > > > > I am clearly not a big fan of this solution. memorg should be and > > remain a read only object. Can you please find another solution? > > > I was debating on this too but I don't see option because there is no other hooks after nanddev_init to set the mtd->oobsize as far as I can see and I see there were similar fixes for other controller drivers after the nand device object init was committed, for example: > Fixes: 629a442cad5f ("mtd: rawnand: Fill memorg during detection") You are right, that was indeed the first approach, I'll remain on this path then. Thanks for the pointer. > > I will think through this again but I am open to any suggestion. > > >> > >> Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") > >> Signed-off-by: William Zhang <william.zhang@broadcom.com> > >> > >> --- > >> > >> Changes in v3: None > >> Changes in v2: None > >> > >> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 +++++-- > >> 1 file changed, 5 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > >> index 407bf79cbaf4..39c7f547db1f 100644 > >> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c > >> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > >> @@ -2647,6 +2647,8 @@ static int brcmnand_setup_dev(struct brcmnand_host *host) > >> struct nand_chip *chip = &host->chip; > >> const struct nand_ecc_props *requirements = > >> nanddev_get_ecc_requirements(&chip->base); > >> + struct nand_memory_organization *memorg = > >> + nanddev_get_memorg(&chip->base); > >> struct brcmnand_controller *ctrl = host->ctrl; > >> struct brcmnand_cfg *cfg = &host->hwcfg; > >> char msg[128]; > >> @@ -2668,10 +2670,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host) > >> if (cfg->spare_area_size > ctrl->max_oob) > >> cfg->spare_area_size = ctrl->max_oob; > >> /* > >> - * Set oobsize to be consistent with controller's spare_area_size, as > >> - * the rest is inaccessible. > >> + * Set mtd and memorg oobsize to be consistent with controller's > >> + * spare_area_size, as the rest is inaccessible. > >> */ > >> mtd->oobsize = cfg->spare_area_size * (mtd->writesize >> FC_SHIFT); > >> + memorg->oobsize = mtd->oobsize; > >> >> cfg->device_size = mtd->size; > >> cfg->block_size = mtd->erasesize; > > > > > > Thanks, > > Miquèl > > Thanks, Miquèl
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c index 407bf79cbaf4..39c7f547db1f 100644 --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c @@ -2647,6 +2647,8 @@ static int brcmnand_setup_dev(struct brcmnand_host *host) struct nand_chip *chip = &host->chip; const struct nand_ecc_props *requirements = nanddev_get_ecc_requirements(&chip->base); + struct nand_memory_organization *memorg = + nanddev_get_memorg(&chip->base); struct brcmnand_controller *ctrl = host->ctrl; struct brcmnand_cfg *cfg = &host->hwcfg; char msg[128]; @@ -2668,10 +2670,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host) if (cfg->spare_area_size > ctrl->max_oob) cfg->spare_area_size = ctrl->max_oob; /* - * Set oobsize to be consistent with controller's spare_area_size, as - * the rest is inaccessible. + * Set mtd and memorg oobsize to be consistent with controller's + * spare_area_size, as the rest is inaccessible. */ mtd->oobsize = cfg->spare_area_size * (mtd->writesize >> FC_SHIFT); + memorg->oobsize = mtd->oobsize; cfg->device_size = mtd->size; cfg->block_size = mtd->erasesize;