From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF265ECDFBB for ; Fri, 20 Jul 2018 13:03:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 700A420661 for ; Fri, 20 Jul 2018 13:03:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 700A420661 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731256AbeGTNwC convert rfc822-to-8bit (ORCPT ); Fri, 20 Jul 2018 09:52:02 -0400 Received: from mail.bootlin.com ([62.4.15.54]:49020 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730998AbeGTNwC (ORCPT ); Fri, 20 Jul 2018 09:52:02 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id CBA9120737; Fri, 20 Jul 2018 15:03:48 +0200 (CEST) Received: from bbrezillon (AAubervilliers-681-1-78-122.w90-88.abo.wanadoo.fr [90.88.20.122]) by mail.bootlin.com (Postfix) with ESMTPSA id 5384A20618; Fri, 20 Jul 2018 15:03:48 +0200 (CEST) Date: Fri, 20 Jul 2018 15:03:48 +0200 From: Boris Brezillon To: Abhishek Sahu Cc: Miquel Raynal , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Andy Gross Subject: Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function Message-ID: <20180720150348.592c8984@bbrezillon> In-Reply-To: <7ab0be154272b71f9beb2a7fb830c7be@codeaurora.org> References: <1530863519-5564-1-git-send-email-absahu@codeaurora.org> <1530863519-5564-3-git-send-email-absahu@codeaurora.org> <20180718232350.3eaade9a@xps13> <20180718234358.6bb5e8a0@bbrezillon> <7ab0be154272b71f9beb2a7fb830c7be@codeaurora.org> 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 On Fri, 20 Jul 2018 17:46:38 +0530 Abhishek Sahu wrote: > Hi Boris, > > On 2018-07-19 03:13, Boris Brezillon wrote: > > On Wed, 18 Jul 2018 23:23:50 +0200 > > Miquel Raynal wrote: > > > >> Boris, > >> > >> Can you please check the change in qcom_nandc_write_oob() is > >> valid? I think it is but as this is a bit of a hack I prefer double > >> checking. > > > > Indeed, it's hack-ish. > > > >> > >> Thanks, > >> Miquèl > >> > >> > >> Abhishek Sahu wrote on Fri, 6 Jul 2018 > >> 13:21:56 +0530: > >> > >> > The NAND base layer calls write_oob() by setting bytes at > >> > chip->badblockpos with value non 0xFF for updating bad block status. > >> > The QCOM NAND controller skips the bad block bytes while doing normal > >> > write with ECC enabled. When initial support for this driver was > >> > added, the driver specific function was added temporarily for > >> > block_markbad() with assumption to change for raw read in NAND base > >> > layer. Moving to raw read for block_markbad() seems to take more time > >> > so this patch removes driver specific block_markbad() function by > >> > using following HACK in write_oob() function. > >> > > >> > Check for BBM bytes in OOB and accordingly do raw write for updating > >> > BBM bytes in NAND flash or normal write for updating available OOB > >> > bytes. > > > > Why don't we change that instead of patching the qcom driver to guess > > when the core tries to mark a block bad? If you're afraid of breaking > > existing drivers that might rely on the "write/read BBM in non-raw > > mode" solution (I'm sure some drivers are), you can always add a new > > flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw > > accessors when this flag is set. > > > > We started with that Only > > http://patchwork.ozlabs.org/patch/508565/ > > and since we didn't conclude, we went for driver > specific bad block check and mark bad block functions. > > Now, we wanted to get rid of driver specific functions > > 1. For bad block check, we found the way to get the BBM bytes > with ECC read. Controller updates BBM in separate register > which we can read and update the same in OOB. Patch #1 of > series does the same. > > 2. For bad block mark, there is no way to update in ECC mode > that's why we went for HACK to get rid of driver specific > function. > > If adding flag is fine now then this HACK won't be required. Yep. I'm fine with that. Can you rebase the patch you pointed out on top of nand/next and move the flag to chip->options instead of chip->bbt_options + prefix it with NAND_ instead of NAND_BBT_? > Moving to RAW mode for every one still looks risky. I agree.