From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751703AbcC2ICu (ORCPT ); Tue, 29 Mar 2016 04:02:50 -0400 Received: from down.free-electrons.com ([37.187.137.238]:44411 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750926AbcC2ICr (ORCPT ); Tue, 29 Mar 2016 04:02:47 -0400 Date: Tue, 29 Mar 2016 10:02:44 +0200 From: Boris Brezillon To: Peter Pan Cc: Ezequiel Garcia , Brian Norris , David Woodhouse , "linux-kernel@vger.kernel.org" , "linux-mtd@lists.infradead.org" , Jiancheng Xue , beanhuo@micron.com, karlzhang@micron.com, Peter Pan Subject: Re: [PATCH 00/11] mtd: nand_bbt: introduce independent nand BBT Message-ID: <20160329100244.0378c763@bbrezillon> In-Reply-To: References: <1457923684-13505-1-git-send-email-peterpandong@micron.com> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, On Mon, 28 Mar 2016 16:20:19 +0800 Peter Pan wrote: > Hi Ezequiel, > > Sorry for reply your mail late. And thaks a lot for reviewing it. > > On Thu, Mar 24, 2016 at 4:57 AM, Ezequiel Garcia > wrote: > > Hello, > > > > On 13 March 2016 at 23:47, Peter Pan wrote: > >> Sorry for send the v3 out late. I went through a busy time in the past > >> two month. > >> > >> Currently nand_bbt.c is tied with struct nand_chip, and it makes other > >> NAND family chips hard to use nand_bbt.c. Maybe it's the reason why > >> onenand has own bbt(onenand_bbt.c). > >> > >> Separate struct nand_chip from BBT code can make current BBT shareable. > >> We create struct nand_bbt to take place of nand_chip in nand_bbt.c. > >> Struct nand_bbt contains all the information BBT needed from outside and > >> it should be embedded into NAND family chip struct (such as struct nand_chip). > >> > >> Below is mtd folder structure we want: > >> drivers/mtd/nand/ > >> drivers/mtd/nand/raw/ > >> drivers/mtd/nand/spi/ > >> drivers/mtd/nand/onenand/ > >> drivers/mtd/nand/chips/ > >> > > > > You mention this structure, but nothing in the current patchset is actually > > enforcing it. This is more the future direction we are going. > > Yes, this is what we want. > > > >> Most of the patch is borrowed from Brian Norris . > >> http://git.infradead.org/users/norris/linux-mtd.git/shortlog/refs/heads/nand-bbt > >> I decided the authorship of each patch by contribution. Please let me know if > >> there is something unproper. > >> Based on Brian's suggestion and Boris's comments, I make 11 independent > >> patches. Previous patch is http://patchwork.ozlabs.org/patch/492066/ > >> After discussion with Boris and Ezequiel, I realized above structure is better, > >> so I drop the patch to move nand_bbt.c to mtd folder. > >> > > > > I have reviewed this patchset, and it looks mostly good to me. I can > > spot trivial style comments, or comments related to the commit logs, or the > > way commits are splitted. > > > > Boris will probably have more insightful comments to make. > > > > However, before starting my silly bikeshedding I'd like to know if we all > > agree with the patchset's overall scheme. > > > > It would be good to finally move forward with this, to take mt29f out > > of staging and also support other SPI NAND vendors. > > Yes. We plan to move mt29f_spi_nand out from staging. But because mt29f_spi_nand > is under raw/parallel NAND framework, it mismatch the stucture we > want. Rewite it > under SPI NAND framework may be a better choice, right? Actually I'm > working on this > now. Yes, that's what I expect. And since this SPI NAND framework does not exist yet, I think it's a good time to create the generic nand_device struct (we'll switch other NAND based devices to this structure afterwards). Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com