On 29 December 2015 at 06:35, Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > Hi, > > On Mon, 28 Dec 2015 17:42:50 -0300 > Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> wrote: > >> This is looking a lot better, thanks for the good work! >> >> On 15 December 2015 at 02:59, Peter Pan <peterpans...@gmail.com> 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> drivers/mtd/nand/spi/<spi-nand-code> drivers/mtd/nand/onenand/<onenand-code> drivers/mtd/nand/chips/<manufacturer-spcific-code> -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
