Message ID | 20230706182909.79151-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:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp2767791vqx; Thu, 6 Jul 2023 11:56:01 -0700 (PDT) X-Google-Smtp-Source: APBJJlEZnsbcwXfBkILgWQxXyPMSBGtcOwvVYnUuKqxLdo/7AhWv7Ggy1nmh2IVWnNiHdqTyCRia X-Received: by 2002:a17:903:110c:b0:1b8:83a3:7db9 with SMTP id n12-20020a170903110c00b001b883a37db9mr2911644plh.23.1688669761184; Thu, 06 Jul 2023 11:56:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688669761; cv=none; d=google.com; s=arc-20160816; b=EtSsxBQCuo93hxNzAUNhSE/9RFH0JF6UlUQUhyXML4dVyaPOzboWOd+NxsOYMJ6I3B qncVyP3T7TNK1amOLzFN0bvNSK9tpoTUE6l9WV7ap0l6YMapMdDfrADfOI7Z1iPyI6T6 DvZs/EIT2KukLGwhft2KpWSnNlKYkEeHU0dgw0Vf9m6ZYTBSilnXfjj/fFmKmuwKM08b Q4tNMgiWDcfVPs+DW9QQNigBgR8aLHLAxorXb2+rBCRWdLXXpY0mQEZd53ZNgzhv5SwM YezKLSwe0wJuXy+a4KwVNwztMyoEbn9HgaL2C7A0pCr58pazrv+TfrttXw7FoNZbe7Vh YnhQ== 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=NsC+L4CHLTDTROKB8tT7c3nb8dVrzJsiNq7PJiTV4iE=; fh=H8oezWVA2uTcgG6ruQ58mVEepH0WZHbgl0y800aHJhs=; b=JdjeE3D4FwB33JSjOPMNzb720xYzgzpM5jSWWjdTM997wKVdpuRE7ifLKsWYdh4YpI 0jjzswXsnefqbFYwKD2i3WAAC2kxuIa2n4cydfh2JjI/SypF6IeqgVdCQMpKqxNat5dN zH6orWC/MpgEeKuAZc2ZvGDuIYM/j26IeRQSEnohWX6DZzNE5QMACPWOEdoFbEzRQ+Mh pe0FO+PvfpvmF2Wuth6O2wywKgNoZ1an5NOy4u+5vVk11gXSbMpv8CRXVY8IraQI0p4T DS1pJrNTykelNIHckDx4ae+7wzMmqTR2sbwt3onfWd1A2oAJcFDSTUnA+zIhmr+ZIF3v yZ1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b="CNpmsWd/"; 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 s12-20020a170903200c00b001b8946f3f95si1686657pla.312.2023.07.06.11.55.44; Thu, 06 Jul 2023 11:56:00 -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="CNpmsWd/"; 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 S232404AbjGFS3t (ORCPT <rfc822;hadasmailinglist@gmail.com> + 99 others); Thu, 6 Jul 2023 14:29:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232068AbjGFS3n (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 6 Jul 2023 14:29:43 -0400 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E91C1FC6 for <linux-kernel@vger.kernel.org>; Thu, 6 Jul 2023 11:29:41 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-66f5faba829so672413b3a.3 for <linux-kernel@vger.kernel.org>; Thu, 06 Jul 2023 11:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1688668180; x=1691260180; h=mime-version:references:in-reply-to:message-id:date:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=NsC+L4CHLTDTROKB8tT7c3nb8dVrzJsiNq7PJiTV4iE=; b=CNpmsWd/o0JDbrA4opR9vlzZhTSFfLbeu6OhuSdnH4VyEDjQ8vFmGhj77PtZBkEY2b SLSklN0DQRzR7abFoss4upzpe8kbcm7DSzIlNrmP9Nu5MrAmozgBshPxdOFLccNVKPJw TUv/bjo0xpg9nouITPLXImMwuBMT3DiKs7qsQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688668180; x=1691260180; 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=NsC+L4CHLTDTROKB8tT7c3nb8dVrzJsiNq7PJiTV4iE=; b=Fn3Uufpe+ezKBk/DrnHpf9pzGXol8jQE3OI0nFX3OMCSvvMaOlO+nx3ASr8/hJc+m1 WCwu3hfCXZ01Qqh3OHS1Bm86a/QjebyDNMMGsIEA+/Wb5O/6EJdg3078Tft89JPBnxT2 Nz1XxUQHgqIhw11DA754FFgOnWrDLiuAQRkhcqBnO+osXzP8BhA4f2EFwwykWSKauATO J0Ky0utbkIdaE4us0BZQKSg66UMGZQHJitYXjG7DWIDIqKdwFX++cSwqUu/RRqSalh09 bq65tbiAE+yE2GCjVkQ0g0orxUM28XtoPMt2pR1uXsijHSjghJ8tWhF2roGUUuo4kLnQ MM8w== X-Gm-Message-State: ABy/qLbX3EQjgPlV0n08HL0MyRxc8vhEOvUMfH0a7X+ET23QkSoVuuCj 5yQz97k4ySoLqdtEQ8wfzJYuUQ== X-Received: by 2002:a05:6a00:1952:b0:679:9639:1f6a with SMTP id s18-20020a056a00195200b0067996391f6amr2572927pfk.14.1688668180394; Thu, 06 Jul 2023 11:29:40 -0700 (PDT) Received: from ubuntu-22.localdomain ([192.19.222.250]) by smtp.gmail.com with ESMTPSA id y13-20020aa7804d000000b006826c9e4397sm1580871pfm.48.2023.07.06.11.29.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Jul 2023 11:29:39 -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 v4 5/5] mtd: rawnand: brcmnand: Fix mtd oobsize Date: Thu, 6 Jul 2023 11:29:09 -0700 Message-Id: <20230706182909.79151-6-william.zhang@broadcom.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230706182909.79151-1-william.zhang@broadcom.com> References: <20230706182909.79151-1-william.zhang@broadcom.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000000e942805ffd5b3d1" 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 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?1770698583388894222?= X-GMAIL-MSGID: =?utf-8?q?1770698583388894222?= |
Series |
mtd: rawnand: brcmnand: driver and doc updates
|
|
Commit Message
William Zhang
July 6, 2023, 6:29 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 v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Comments
On Thu, 2023-07-06 at 18:29:09 UTC, William Zhang wrote: > 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> 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/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c index 71d0ba652bee..39661e23d7d4 100644 --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c @@ -2652,6 +2652,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]; @@ -2673,10 +2675,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;