Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1009532imu; Thu, 20 Dec 2018 08:41:06 -0800 (PST) X-Google-Smtp-Source: AFSGD/WvMW+54y2MhLZBhX3OkeCcF+IjBkNb1PDbMvvtyiB8rPVmkQGQFe9BqwA4SkhnpLuKg/tL X-Received: by 2002:a63:6506:: with SMTP id z6mr10733168pgb.334.1545324066125; Thu, 20 Dec 2018 08:41:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545324066; cv=none; d=google.com; s=arc-20160816; b=0Ho9Itvf1niW+ruOmTiHdFLmZ01JIXiz1DUlUnZ6FVgQ+sKNaim+5Y9CFzvvQjuNq7 gVrNk7ver3ARhJE+VkY5t0mX/rHEH0w8WZEk5efvhtaXauaTjBwPigw1P8YuWqL7T4Bu THJIOkPItVGC4N/zJ4KRW0E5RS4/9PqTFeJdAEwgRKKgLfx4V4q2kcEyNBk9EAzMglBb vAHfM5Zd5DM7jkxKwVR53JctpDsvFmRuKDs6UYtMo3z9JMrH41bCSBQWmuzW7tyZ65bF mcKjLdf2BNeEQqAJFFpgpVIR2gIQdfjtFwJqt/qjaBDpAgGctBP0R35Gn/5aXpt31Qfk wrIg== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=y9vq27rrjWgJiCPFgVRbQ/EijKQycS6D9Opgj78vujg=; b=NRe00LfMJczEeVtR0iqASMbfHnj5cwBHOXas5S2P3j8vO7Uro9OuD2CRcRP4p63lhn Xa6PUslM5URQEvpoUaARHu+QHIPX7CL/jY63Mr+eY3u2JSw0vterJNwAKqYUQi8wUFxg eKuQMgskLEU9hPcl1B2VPa1m0Gn0JS22G1i5mgfw0t4t2LjO94qy4f9ai5NkGoF86EjU To3h8EB82LLGn0AFOwBQQXD7lWlCPEVoEM95b7JZXF0U0aVYSXaSPERKBImqEwSQBxni /URxrYgIsbFVOpwsK42LtlcBFDa6j7PeOBBy+ES82wWUOZTBizwmaFwTCmAJbkUEzNzu 7ZHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Eq8NxRLe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x9si18809942pgh.12.2018.12.20.08.40.50; Thu, 20 Dec 2018 08:41:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Eq8NxRLe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731719AbeLTPm2 (ORCPT + 99 others); Thu, 20 Dec 2018 10:42:28 -0500 Received: from mail.kernel.org ([198.145.29.99]:58896 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729184AbeLTPm2 (ORCPT ); Thu, 20 Dec 2018 10:42:28 -0500 Received: from bbrezillon (aaubervilliers-681-1-38-38.w90-88.abo.wanadoo.fr [90.88.157.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B4B79218C3; Thu, 20 Dec 2018 15:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1545320546; bh=R+F+94HY4VpHQ61nKLHhmb0RU0nanxD1zU7DStU3e8s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Eq8NxRLeVaEjhDBps1AmhJ60nu9YDOh/3Dp7oMxuXWjW30QjBo2fZYUvp0CQqayIw KWnezHfgT0BfPz/Rs6Qk62WXLdWRbtVklIsmOilfA/lgfo4Av/F6JXqXVlkEwg7Kru hdPNUpne08ebqCVHtl8KCnhbn3jCycSikgqvA3GU= Date: Thu, 20 Dec 2018 16:42:21 +0100 From: Boris Brezillon To: Schrempf Frieder Cc: "richard@nod.at" , "linux-kernel@vger.kernel.org" , Marek Vasut , "linux-mtd@lists.infradead.org" , "miquel.raynal@bootlin.com" , Brian Norris , David Woodhouse Subject: Re: [PATCH 1/3] mtd: rawnand: Support bad block markers in first, second or last page Message-ID: <20181220164221.0fb76fe1@bbrezillon> In-Reply-To: References: <1545061693-29216-1-git-send-email-frieder.schrempf@kontron.de> <1545061693-29216-2-git-send-email-frieder.schrempf@kontron.de> <20181220145954.55ae36e9@bbrezillon> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Frieder, On Thu, 20 Dec 2018 14:35:05 +0000 Schrempf Frieder wrote: > On 20.12.18 14:59, Boris Brezillon wrote: > > On Mon, 17 Dec 2018 15:49:07 +0000 > > Schrempf Frieder wrote: > > > >> From: Frieder Schrempf > >> > >> Currently supported bad block marker positions within the block are: > >> * in first page only > >> * in last page only > >> * in first or second page > >> > >> Some ESMT NANDs are known to have been shipped by the manufacturer > >> with bad block markers in the first or last page, instead of the > >> first or second page. > >> > >> Also the datasheets for Cypress/Spansion/AMD NANDs claim that the > >> first, second *and* last page needs to be checked. > >> > >> Therefore we make it possible to set NAND_BBT_SCAN2NDPAGE and > >> NAND_BBT_SCANLASTPAGE at the same time to scan/set all three pages. > >> > >> To simplify the code, the logic to evaluate the flags is moved to a > >> a new function nand_bbm_page_offset(). > >> > >> Signed-off-by: Frieder Schrempf > >> --- > >> drivers/mtd/nand/raw/internals.h | 1 + > >> drivers/mtd/nand/raw/nand_base.c | 72 ++++++++++++++++++++++++++--------- > >> drivers/mtd/nand/raw/nand_bbt.c | 30 +++++++-------- > >> 3 files changed, 68 insertions(+), 35 deletions(-) > >> > >> diff --git a/drivers/mtd/nand/raw/internals.h b/drivers/mtd/nand/raw/internals.h > >> index 04c2cf7..8e4b168 100644 > >> --- a/drivers/mtd/nand/raw/internals.h > >> +++ b/drivers/mtd/nand/raw/internals.h > >> @@ -76,6 +76,7 @@ extern const struct nand_manufacturer_ops toshiba_nand_manuf_ops; > >> > >> /* Core functions */ > >> const struct nand_manufacturer *nand_get_manufacturer(u8 id); > >> +int nand_bbm_page_offset(struct nand_chip *chip, int index); > >> int nand_markbad_bbm(struct nand_chip *chip, loff_t ofs); > >> int nand_erase_nand(struct nand_chip *chip, struct erase_info *instr, > >> int allowbbt); > >> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c > >> index 71050a0..388d9ed 100644 > >> --- a/drivers/mtd/nand/raw/nand_base.c > >> +++ b/drivers/mtd/nand/raw/nand_base.c > >> @@ -253,6 +253,45 @@ static void nand_release_device(struct mtd_info *mtd) > >> } > >> > >> /** > >> + * nand_bbm_page_offset - Get the page offsets for bad block markers > >> + * @chip: NAND chip object > >> + * @index: Index for the page offset > > > > Hm, the meaning of index is far from obvious. How about passing the > > current page instead (and return 1 if there are more pages to scan 0 > > otherwise)? > > Good idea. > > > > > Something like: > > > > static int nand_bbm_get_next_page(struct nand_chip *chip, int page) > > { > > struct mtd_info *mtd = nand_to_mtd(chip); > > int last_page = ((mtd->erasesize - mtd->writesize) >> > > chip->page_shift) & chip->pagemask; > > > > if (page < 0 && chip->bbt_options & NAND_BBT_SCANFIRSTPAGE) > > return 0; > > else if (page < 1 && chip->bbt_options & NAND_BBT_SCAN2NDPAGE) > > return 1; > > else if (page < last_page && > > chip->bbt_options & NAND_BBT_SCANLASTPAGE) > > return last_page; > > > > return -1; > > } > > > > And yes, that means defining NAND_BBT_SCANFIRSTPAGE and setting it when > > appropriate. > > I tried to keep the existing flags and their current meanings, but you > are right. If we redefine the flags and add NAND_BBT_SCANFIRSTPAGE and > NAND_BBT_SCANFIRST2PAGES this will be much easier to read. > > Also maybe renaming the flags to NAND_BBM_XXX would be even cleaner, as > we use them not only for scanning, but also for writing markers and they > are not directly related to the bad block table (BBT)? Yep, and maybe move them to chip->options too. > > By the way, what are your plans for using the common NAND layer (that is > used by the SPI NAND layer) for raw NAND? I'd still like to have this done at some point, just don't have the time to do it myself ;-). I started working on that a few weeks back [1], but didn't have time to finish it. > I'm thinking of SPI NANDs that might require things like this, too. Yes, probably. > Currently they seem to have the markers in the first page only, but that > could change easily and in that case it would be nice to share the code. Yes. Actually, that's the whole BBT + BBM scanning logic we should make generic. But I'd like to take this as an opportunity to cleanup/simplify the bbt code instead of simply porting it to the generic NAND layer. If you have some time, feel free to finish what I started. Regards, Boris [1]https://github.com/bbrezillon/linux/commits/nand/cleanup