Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp687210ybg; Fri, 12 Jun 2020 11:52:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxRy3yJfT8URgC+NAMKyIEImUrDIbrMVl3MxUR9Y+Td8tCpWnwFnNCSgG/zqTDfbb5KbZ9 X-Received: by 2002:a17:906:7746:: with SMTP id o6mr14928282ejn.75.1591987932877; Fri, 12 Jun 2020 11:52:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591987932; cv=none; d=google.com; s=arc-20160816; b=nQIDOudi2XqvBT/dKktUUYXfE2s1VWVA+ebdy0F2uXj05GzKGfFKzZv28KU7Pu1vsJ gc3wdWqHU4edVKPBzEv2ILiWp891JsMmgZf9ki7kxtkb9I6xfJPDC6ArYv0pNZnTtpfj k+IScR8MFi9MQ0N7TWZ5IPOGjIFEqKBjVnP66qcDt+SOp8DwKBb+c0XP1bSGBJdeXK3H 9deocye+5DTjehf4K7IffQCEnQRJPwMGBCVD88G5Av6fdq3FgtbyUg2XZ6HUS/Twkiyy krpDJFKk25FfCLDmiAFRWV895jJAREG773eu/nKKVpGETdQ51UDEvb4eWkS9o3xmiQEb o8xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=LZDy9XcI4N1lUd1gGa7ISl9lwNSdZf1QWRf62wPMnVw=; b=A3TZ1Tbj0BfXaHL5kwndAhtizoCDhwsssW3NlLhQbV3cg98uPEsz1lrSPyyPeazWum HKZw/SShyKuPP4N/BrDgf7NYrhUNTsAgA9F8BQCLEkfjGsKwq6SFLWAXBsr1owbqhOGJ HCqGC3vDWUzU9pfV65PF7F8Mt6VvdW3BnygQp22/OV2ob3IL845oQ1TWRrXqgYh1Wi6X +RgKM3yVAWD/5SBhI1rJbIeky/H2em8n6TotEsICbwFJSVUzgJCWlMMPzCDESoPNTwHB 4uKaMdKYJ7n5U47eJjg2vQgLu4jtzcLrxPc0Li6NJwY+YYUCYHyjEXehJYGm0Uc0bgSY cJvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=S2x9dGEH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k14si4429999ejz.68.2020.06.12.11.51.49; Fri, 12 Jun 2020 11:52:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=S2x9dGEH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726349AbgFLSru (ORCPT + 99 others); Fri, 12 Jun 2020 14:47:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726268AbgFLSrt (ORCPT ); Fri, 12 Jun 2020 14:47:49 -0400 Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2093C03E96F; Fri, 12 Jun 2020 11:47:49 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id x189so2239329iof.9; Fri, 12 Jun 2020 11:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LZDy9XcI4N1lUd1gGa7ISl9lwNSdZf1QWRf62wPMnVw=; b=S2x9dGEHkOnJf+7GpQkXBNyZgMb+NG5lpVqGB+F8ObbicBblcPnt1Zj0z2T2BJN1ak BE5tyB3SXO/vcPpoE1SV0kY1Hyiuhx8BaCvyI4y2wl5zVlTziIxk6WAAGlfkyrGWK2Ab ZJmk91KRA2HRL5FDYwjDYXfdoxwSeDYU2+fZ5Z8Mkt+x8+aREd4LyXa1focAkMeBM167 RGDhyMr0dOAIZK/jg79jEb+znkyhK/DuF8F1TzcM7Ak+2abPElSzvfEwgLwHRZ/tiXLT XcVd6vAWGmnp9IO5dm4LC11qH4Ycso5wykJuil7n4kQNX5Uq5tVU5q/eYugeOmAWp9i4 NGUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LZDy9XcI4N1lUd1gGa7ISl9lwNSdZf1QWRf62wPMnVw=; b=Wugerj51NeCUivMnRVXoyO0tDkrZ+JBGsATk6DIN0w1zDfuLheiMC9ryCHlh38vdDW 3Pr+jyo7D9n/ToGOr5DSczfFM6uPjCJpOG+yILvgwxCpKOWwqRQmropefAmNt8A1Xdtw x0apvtMYr/MJBjAwVPORLsWqacQAX0dEzjZnSCodvKWuUlH3RIgR7+Qvb6EXAvorZP9W 4xwsYa9VwNApTKspcOdCHDv7tsnQA3FC040F9//kptPv+ONBnnkEM58c+CA2Dz0hrAGT tAZp/XqexR8scpsjgeVD2PmunY8prQGesgSRYdx5zfsB2Ffx/0lGQXiu6Z1HtTGqym2t kxBg== X-Gm-Message-State: AOAM531gW2iZA1E/vlRn3Vh6cGKQ2YfEoFcl72i65Lt0qLkY4VEppCfa 9SKzIwvEajfeOefJ1SUGmaeN5eBuZ+5v//ce428= X-Received: by 2002:a05:6602:1601:: with SMTP id x1mr15442631iow.129.1591987668271; Fri, 12 Jun 2020 11:47:48 -0700 (PDT) MIME-Version: 1.0 References: <20200605170720.2478262-1-noltari@gmail.com> In-Reply-To: <20200605170720.2478262-1-noltari@gmail.com> From: Kamal Dasu Date: Fri, 12 Jun 2020 14:47:37 -0400 Message-ID: Subject: Re: [PATCH] mtd: rawnand: brcmnand: force raw OOB writes To: =?UTF-8?B?w4FsdmFybyBGZXJuw6FuZGV6IFJvamFz?= Cc: Brian Norris , Miquel Raynal , Richard Weinberger , "R, Vignesh" , Sumit Semwal , MTD Maling List , bcm-kernel-feedback-list , Linux Kernel Mailing List , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 5, 2020 at 1:07 PM =C3=81lvaro Fern=C3=A1ndez Rojas wrote: > > MTD_OPS_AUTO_OOB is writting OOB with ECC enabled, which changes all ECC = bytes > from an erased page to 0x00 when JFFS2 cleanmarkers are added with mtd-ut= ils. > | BBI | JFFS2 | ECC | JFFS2 | Spare | > 00000800 ff ff 19 85 20 03 00 00 00 00 00 00 08 ff ff ff > > However, if OOB is written with ECC disabled, the JFFS2 cleanmarkers are > correctly written without changing the ECC bytes: > | BBI | JFFS2 | ECC | JFFS2 | Spare | > 00000800 ff ff 19 85 20 03 ff ff ff 00 00 00 08 ff ff ff Both brcmand_write_oob_raw() and brcmnand_write_oob() use brcmnand_write() that uses PROGRAM_PAGE cmd, means also programs data areas and ECC when enabled is always calculated on DATA+OOB. since in both cases we only want to modify OOB, data is always assumed to be 0xffs (means erased state). So as far as this api always is used on the erased page it should be good. Are the sub-pages/oob areas read by jffs2 also read without ecc enabled?. Just want to be sure that it does not break any other utilities like nandwrite. > > Signed-off-by: =C3=81lvaro Fern=C3=A1ndez Rojas > --- > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 9 +-------- > 1 file changed, 1 insertion(+), 8 deletions(-) > > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/= raw/brcmnand/brcmnand.c > index 8f9ffb46a09f..566281770841 100644 > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > @@ -2279,13 +2279,6 @@ static int brcmnand_write_page_raw(struct nand_chi= p *chip, const uint8_t *buf, > return nand_prog_page_end_op(chip); > } > > -static int brcmnand_write_oob(struct nand_chip *chip, int page) > -{ > - return brcmnand_write(nand_to_mtd(chip), chip, > - (u64)page << chip->page_shift, NULL, > - chip->oob_poi); > -} > - > static int brcmnand_write_oob_raw(struct nand_chip *chip, int page) > { > struct mtd_info *mtd =3D nand_to_mtd(chip); > @@ -2642,7 +2635,7 @@ static int brcmnand_init_cs(struct brcmnand_host *h= ost, struct device_node *dn) > chip->ecc.write_oob_raw =3D brcmnand_write_oob_raw; > chip->ecc.read_oob_raw =3D brcmnand_read_oob_raw; > chip->ecc.read_oob =3D brcmnand_read_oob; > - chip->ecc.write_oob =3D brcmnand_write_oob; > + chip->ecc.write_oob =3D brcmnand_write_oob_raw; > > chip->controller =3D &ctrl->controller; > > -- > 2.26.2 >