linux-kernel - Re: [PATCH 02/11] mtd: nand_bbt: introduce BBT related data structure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160419093424.27cfc585@bbrezillon>
Date:	Tue, 19 Apr 2016 09:34:24 +0200
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	Peter Pan <peterpansjtu@...il.com>
Cc:	Brian Norris <computersforpeace@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
	karlzhang@...ron.com, beanhuo@...ron.com,
	Jiancheng Xue <xuejiancheng@...wei.com>,
	Peter Pan <peterpandong@...ron.com>
Subject: Re: [PATCH 02/11] mtd: nand_bbt: introduce BBT related data
 structure

Hi Peter,

On Tue, 19 Apr 2016 08:40:40 +0800
Peter Pan <peterpansjtu@...il.com> wrote:
> 
> >
> >> So it's true, it
> >> should still be numchips in nand_bbt.c?  I just came out this question when
> >> making v4. :)
> >
> > BTW, I have something for you [1]. I started to move things around to
> > allow spinand and onenand layers to lie under drivers/mtd/nand/, and I
> > wonder if we shouldn't do this move before reworking the nand_bbt code
> > to make it generic.
> > Note that this rework is not finished yet, but it gives a rough idea of
> > what I'd like to see.
> 
> I saw you also rework BBT in your git tree, which is a bit duplicate
> with my BBT patch,
> so should I continue my BBT patch by join part of your BBT rework code
> or continue
> your git tree ?

Well, if you ask me what I'd prefer, it's clearly the 2nd solution.
Note that my branch should just serve as a reference of what I expect,
it just a pile of rework that should probably be reordered and cleaned
up.

Here's the sequencing I'd like to see:

1/ Move include/linux/mtd/nand.h into include/linux/mtd/rawnand.h and
   move all files under drivers/mtd/nand/ into
   drivers/mtd/nand/rawnand (including nand_bbt.c). This can be done in
   several patches

2/ Add the generic nand layer (include/linux/mtd/nand.h and
   drivers/mtd/nand/core.c). In my version I put everything in
   include/linux/mtd/nand.h, but maybe we'll need a few functions to be
   defined in drivers/mtd/nand/core.c.

3/ Create a rawnand_device structure inheriting from nand_device, and
   then make nand_chip inherit from rawnand_device. Patch the
   nand_base.c code to initialize all the nand_device fields properly,
   so that we'll be ready to switch to the generic BBT code.

4/ Modify the nand_bbt.c code to make use of the generic NAND interface
   instead of the MTD and rawnand one (this implies identifying all the
   generic helpers you might need, and implementing them in
   include/linux/mtd/nand.h or drivers/mtd/nand/core.c).

5/ Move drivers/mtd/nand/rawnand/nand_bbt.c into
   drivers/mtd/nand/bbt.c

6/[optional] Implement your spinand layer in drivers/mtd/nand/spinand

I know I'm asking a lot, especially given that you already spent a lot
of time iterating on this BBT rework series. But your goal is to move
mt29f driver out of staging, and you'll need to do the generic NAND
layer to achieve that, so I'd really prefer having the BBT code use
this generic layer instead of directly using the MTD API + an extra set
of NAND specific structs (like the nand_chip_layout_info one).

Let me know if you think otherwise.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com