From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from down.free-electrons.com ([37.187.137.238] helo=mail.free-electrons.com) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aGp5t-0004aF-9I for linux-mtd@lists.infradead.org; Wed, 06 Jan 2016 14:29:46 +0000 Date: Wed, 6 Jan 2016 15:29:22 +0100 From: Boris Brezillon To: =?UTF-8?B?5r2Y5qCL?= Cc: Brian Norris , "linux-kernel@vger.kernel.org" , Peter Pan , "linux-mtd@lists.infradead.org" , Ezequiel Garcia , karlzhang@micron.com, Frans Klaver , David Woodhouse , beanhuo@micron.com Subject: Re: [PATCH v2 00/12] mtd: nand_bbt: introduce independent nand BBT Message-ID: <20160106152922.0f08a94c@bbrezillon> In-Reply-To: <20151230093106.6b1ee118@bbrezillon> References: <1450159178-29895-1-git-send-email-peterpandong@micron.com> <20151229103519.31ccaf5c@bbrezillon> <20151229161156.77060900@bbrezillon> <20151230093106.6b1ee118@bbrezillon> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 30 Dec 2015 09:31:06 +0100 Boris Brezillon wrote: > Hi Peter, >=20 > On Wed, 30 Dec 2015 15:18:39 +0800 > =E6=BD=98=E6=A0=8B wrote: >=20 > > Hi Boris and Ezequiel, > >=20 > > 2015-12-29 23:11 GMT+08:00 Boris Brezillon : > > > On Tue, 29 Dec 2015 12:07:50 -0300 > > > Ezequiel Garcia wrote: > > > > > >> On 29 December 2015 at 06:35, Boris Brezillon > > >> wrote: > > >> > Hi, > > >> > > > >> > On Mon, 28 Dec 2015 17:42:50 -0300 > > >> > Ezequiel Garcia wrote: > > >> > > > >> >> This is looking a lot better, thanks for the good work! > > >> >> > > >> >> On 15 December 2015 at 02:59, Peter Pan = wrote: > > >> >> > Currently nand_bbt.c is tied with struct nand_chip, and it make= s 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 sh= areable. > > >> >> > We create struct nand_bbt to take place of nand_chip in nand_bb= t.c. > > >> >> > Struct nand_bbt contains all the information BBT needed from ou= tside and > > >> >> > it should be embedded into NAND family chip struct (such as str= uct nand_chip). > > >> >> > NAND family driver should allocate, initialize and free struct = nand_bbt. > > >> >> > > > >> >> > Below is mtd folder structure we want: > > >> >> > mtd > > >> >> > =E2=94=9C=E2=94=80=E2=94=80 Kconfig > > >> >> > =E2=94=9C=E2=94=80=E2=94=80 Makefile > > >> >> > =E2=94=9C=E2=94=80=E2=94=80 ... > > >> >> > =E2=94=9C=E2=94=80=E2=94=80 nand_bbt.c > > >> >> > > >> >> Hm.. I'm not sure about having nand_bbt.c in drivers/mtd. > > >> >> What's wrong with drivers/mtd/nand ? > > >> > > > >> > I haven't reviewed the series yet, but I agree. If the BBT code is= only > > >> > meant to be used on NAND based devices, it should probably stay in > > >> > drivers/mtd/nand. > > >> > > > >> >> > > >> >> In fact, I was thinking we could go further and clean up the dir= ectories a bit > > >> >> by separating core code, from controllers code, from SPI NAND cod= e: > > >> >> > > >> >> drivers/mtd/nand/ > > >> >> drivers/mtd/nand/controllers > > >> >> drivers/mtd/nand/spi > > >> >> > > >> >> Makes any sense? > > >> > > > >> > Actually I had the secret plan of moving all (raw) NAND controller > > >> > drivers into the drivers/mtd/nand/controllers directory, though th= is > > >> > was for a different reason: I'd like to create another directory f= or > > >> > manufacturer specific code in order to support some advanced featu= res > > >> > on NANDs that do not implement (or only partially implement) the O= NFI > > >> > standard. > > >> > > > >> > The separation you're talking about here is more related to the > > >> > interface used to communicate with the NAND chip. > > >> > > > >> > How about using the following hierarchy? > > >> > > > >> > drivers/mtd/nand/ > > >> > drivers/mtd/nand/interfaces/raw/ > > >> > drivers/mtd/nand/interfaces/raw/controllers/ > > >> > drivers/mtd/nand/interfaces/spi/ > > >> > drivers/mtd/nand/interfaces/onenand/ > > >> > drivers/mtd/nand/chips/ > > >> > > > >> > What do you think? > > >> > > > >> > > >> I believe we are bikeshedding here, but what the heck. > > >> > > >> That seems too involved. A simpler hierarchy could be clear enough, > > >> and seems to follow what other subsystems do: > > >> > > >> drivers/mtd/nand/ > > >> drivers/mtd/nand/raw/ > > > > > > And probably some common logic in there too. > > > > > >> drivers/mtd/nand/spi/ > > >> drivers/mtd/nand/onenand/ > > >> drivers/mtd/nand/chips/ > > >> > > > > > > I'm fine with this one too ;-). > >=20 > > I'm fine with this structure too. drivers/mtd/nand folder becomes top f= older for > > all NAND based devices. Because (raw)NAND, SPI-NAND and ONENAND have > > different command set and feature, each has its own core - nand_base.c > > spi-nand-base.c > > and onenand_base.c. So maybe it'll take a lot effort to abstract a > > all-nand-core-code > > (of course BBT should be one of them). What's your opinion? >=20 > Absolutely, that was the idea: move everything into the > drivers/mtd/nand directory (with the structure described above), keep > some specific logic for each interface type, and see if we can factor > out some common code (I noticed that SPI NAND devices have a parameter > page which looks similar to the one exposed by ONFI compliant devices, > except this parameter page is retrieved using a different command, the > same goes for the ->{set,get}_features() functions). > But let's focus on the nand_bbt code for now. >=20 > >=20 > > Also, please review the BBT patch if you have time. I think it's > > helpful on the new NAND code > > hierarchy. >=20 > I'll try to review it this week. I'm a bit late, but I think I've reviewed most of it now. --=20 Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com