Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2045891imm; Mon, 28 May 2018 00:04:25 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrNYpb4Zqi1/nqJrW2fD6wWW5umu1nbj6k1xFgYszKH8lhQPmGIR4sIsJnaMxYGVGjGkK75 X-Received: by 2002:a62:845:: with SMTP id c66-v6mr12373776pfd.189.1527491065277; Mon, 28 May 2018 00:04:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527491065; cv=none; d=google.com; s=arc-20160816; b=GOFAo2yKIvblDMhC3cVXw4c37YCQO9pKKDTsY2LtmUJ6itk3Tu6Dcvp5PADwQhwvkW cWCv3M/chId4vdPn5fthegQX2v5Ss+SF7qKItwwItuSDZfvWHpUUmFfo2OuGKfgZvPUV btYPxcfIbXSJsr7DEcf4Nr6AAhc6iZ37411OnRI+r0c2jimmdFQ4p/bk/Xvi1LEhPUIM bVMcyyVxYwQf6v+tyUNseb227NnQnV8WXdvwqkenWKe3uCZbL/vl0Ta/poaN+QU9VVUB yRL+tTn91o2f6RVp/L4/zslveXWI18OR0DY69lrwPhypp7dLqMc9OB29pX2xWX7GgSK7 M3wQ== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=GRtmGcjbqFBxqhcNsDGlhhTouoqZp0DbwlwB7J3SsK8=; b=Y32oJ4eBTf7CRj9SRo9wf7ZEEvn/Q9tEtq/IVd6azd8UECRMVYuMKi8ITDyCHcZrYX 8yDO+U75f2pORVlPfb+2rsdtlnhc7VEWZbWdbcLFCDqQI7+ojDs8FA2AejevqF+cLOsO O7z9/o7l0scMtVCLQIP9eLjcUxTU1BVUxfCdXYVuF7+I5A+a7m6UKc1/o4Heq3mHPXWl feTWxc7u/iBBqXBSWy1TvzkcpGt2iTYf1BOMxbM50I6t1zN0b0kdAHUGEK3VnXOn6TSi 3Y1bpmYdmroZIRdWg9DbBgDIJSF2kUYEFOOjYGxhr41FoIt3Rs5bvmWkRJk06v0hlqM1 8hVA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s23-v6si30112364plr.458.2018.05.28.00.04.10; Mon, 28 May 2018 00:04:25 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753810AbeE1HEB convert rfc822-to-8bit (ORCPT + 99 others); Mon, 28 May 2018 03:04:01 -0400 Received: from mail.bootlin.com ([62.4.15.54]:34743 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753779AbeE1HDz (ORCPT ); Mon, 28 May 2018 03:03:55 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id CA19720750; Mon, 28 May 2018 09:03:53 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from xps13 (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.bootlin.com (Postfix) with ESMTPSA id 71B7D20012; Mon, 28 May 2018 09:03:53 +0200 (CEST) Date: Mon, 28 May 2018 09:03:52 +0200 From: Miquel Raynal To: Abhishek Sahu Cc: Boris Brezillon , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Cyrille Pitchen , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Andy Gross , Archit Taneja Subject: Re: [PATCH v3 13/16] mtd: rawnand: qcom: minor code reorganization for bad block check Message-ID: <20180528090352.254022ed@xps13> In-Reply-To: <90ae248edf8a06a1d35e2da458f75af5@codeaurora.org> References: <1527250904-21988-1-git-send-email-absahu@codeaurora.org> <1527250904-21988-14-git-send-email-absahu@codeaurora.org> <20180526104629.74315561@xps13> <90ae248edf8a06a1d35e2da458f75af5@codeaurora.org> Organization: Bootlin X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Abhishek, > >> /* implements ecc->read_page() */ > >> static int qcom_nandc_read_page(struct mtd_info *mtd, struct >> nand_chip *chip, > >> uint8_t *buf, int oob_required, int page) > >> @@ -2118,6 +2083,7 @@ static int qcom_nandc_block_bad(struct mtd_info >> *mtd, loff_t ofs) > >> struct nand_ecc_ctrl *ecc = &chip->ecc; > >> int page, ret, bbpos, bad = 0; > >> u32 flash_status; > >> + u8 *bbm_bytes_buf = chip->data_buf; > >> >> page = (int)(ofs >> chip->page_shift) & chip->pagemask; > >> >> @@ -2128,11 +2094,31 @@ static int qcom_nandc_block_bad(struct >> mtd_info *mtd, loff_t ofs) > >> * that contains the BBM > >> */ > >> host->use_ecc = false; > >> + bbpos = mtd->writesize - host->cw_size * (ecc->steps - 1); > > > Are we sure there is no layout with only 1 step? > > All the layouts are such that, the BBM will come in > first byte of spare area. > > For 4 bit ECC, the cw_size is 528 so for 2K page > > 2048 - 528 * 3 = 464 My question was more about small page NANDs. But I suppose it works too if ecc->steps == 1. > > So for last CW, the 464 is BBM (i.e 2048th byte) in > full page. > > > >> >> clear_bam_transaction(nandc); > >> - ret = copy_last_cw(host, page); > >> - if (ret) > >> + clear_read_regs(nandc); > >> + > >> + set_address(host, host->cw_size * (ecc->steps - 1), page); > >> + update_rw_regs(host, 1, true); > >> + > >> + /* > >> + * The last codeword data will be copied from NAND device to NAND > >> + * controller internal HW buffer. Copy only required BBM size bytes > >> + * from this HW buffer to bbm_bytes_buf which is present at > >> + * bbpos offset. > >> + */ > >> + nandc_set_read_loc(nandc, 0, bbpos, host->bbm_size, 1); > >> + config_nand_single_cw_page_read(nandc); > >> + read_data_dma(nandc, FLASH_BUF_ACC + bbpos, bbm_bytes_buf, > >> + host->bbm_size, 0); > >> + > >> + ret = submit_descs(nandc); > >> + free_descs(nandc); > >> + if (ret) { > >> + dev_err(nandc->dev, "failed to copy bad block bytes\n"); > >> goto err; > >> + } > >> >> flash_status = le32_to_cpu(nandc->reg_read_buf[0]); > >> >> @@ -2141,12 +2127,10 @@ static int qcom_nandc_block_bad(struct >> mtd_info *mtd, loff_t ofs) > >> goto err; > >> } > >> >> - bbpos = mtd->writesize - host->cw_size * (ecc->steps - 1); > >> - > >> - bad = nandc->data_buffer[bbpos] != 0xff; > >> + bad = bbm_bytes_buf[0] != 0xff; > > > This is suspect as it still points to the beginning of the data buffer. > > Can you please check you did not meant bbm_bytes_buf[bbpos]? > > > The main thing here is > nandc_set_read_loc(nandc, 0, bbpos, host->bbm_size, 1); > > After reading one complete CW from NAND, the data will be still > in NAND HW buffer. > > The above register tells that we need to read data from > bbpos of size host->bbm_size (which is 1 byte for 8 bus witdh > and 2 byte for 16 bus width) in bbm_bytes_buf. I see: idx 0 in bbm_bytes_buf is the data at offset bbpos. Then it's ok. > > So bbm_bytes_buf[0] will contain the BBM first byte. > and bbm_bytes_buf[1] will contain the BBM second byte. > > Regards, > Abhishek > > >> >> if (chip->options & NAND_BUSWIDTH_16) > >> - bad = bad || (nandc->data_buffer[bbpos + 1] != 0xff); > >> + bad = bad || (bbm_bytes_buf[1] != 0xff); Sorry, my mistake, I did not see the above line. However, technically, the BBM could be located in the first, second or last page of the block. You should check the three of them are 0xFF before declaring the block is not bad. The more I look at the function, the more I wonder if you actually need it. Why does the generic nand_block_bad() implementation in the core do not fit? > >> err: > >> return bad; > >> } > > > > Thanks, > > Miquèl