Hi Boris and Ezequiel, 2015-12-29 23:11 GMT+08:00 Boris Brezillon <[email protected]>: > On Tue, 29 Dec 2015 12:07:50 -0300 > Ezequiel Garcia <[email protected]> wrote: > >> On 29 December 2015 at 06:35, Boris Brezillon >> <[email protected]> wrote: >> > Hi, >> > >> > On Mon, 28 Dec 2015 17:42:50 -0300 >> > Ezequiel Garcia <[email protected]> wrote: >> > >> >> This is looking a lot better, thanks for the good work! >> >> >> >> On 15 December 2015 at 02:59, Peter Pan <[email protected]> wrote: >> >> > 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). >> >> > NAND family driver should allocate, initialize and free struct nand_bbt. >> >> > >> >> > Below is mtd folder structure we want: >> >> > mtd >> >> > ├── Kconfig >> >> > ├── Makefile >> >> > ├── ... >> >> > ├── 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 directories >> >> a bit >> >> by separating core code, from controllers code, from SPI NAND code: >> >> >> >> 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 this >> > was for a different reason: I'd like to create another directory for >> > manufacturer specific code in order to support some advanced features >> > on NANDs that do not implement (or only partially implement) the ONFI >> > 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/<nand-core-code> >> > drivers/mtd/nand/interfaces/raw/<raw-nand-core-code> >> > drivers/mtd/nand/interfaces/raw/controllers/<raw-nand-controller-drivers> >> > drivers/mtd/nand/interfaces/spi/<spi-nand-code> >> > drivers/mtd/nand/interfaces/onenand/<onenand-code> >> > drivers/mtd/nand/chips/<manufacturer-spcific-code> >> > >> > 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/<all-nand-core-code> >> drivers/mtd/nand/raw/<raw-nand-controller-drivers> > > And probably some common logic in there too. > >> drivers/mtd/nand/spi/<spi-nand-code> >> drivers/mtd/nand/onenand/<onenand-code> >> drivers/mtd/nand/chips/<manufacturer-spcific-code> >> > > I'm fine with this one too ;-).
I'm fine with this structure too. drivers/mtd/nand folder becomes top folder 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? Also, please review the BBT patch if you have time. I think it's helpful on the new NAND code hierarchy. > > -- > Boris Brezillon, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com Thanks Peter Pan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
