linux-kernel - Re: [PATCH 00/11] mtd: nand_bbt: introduce independent nand BBT

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]

Date:	Wed, 23 Mar 2016 17:57:12 -0300
From:	Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
To:	Peter Pan <peterpansjtu@...il.com>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	Brian Norris <computersforpeace@...il.com>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	Jiancheng Xue <xuejiancheng@...wei.com>, beanhuo@...ron.com,
	karlzhang@...ron.com, Peter Pan <peterpandong@...ron.com>
Subject: Re: [PATCH 00/11] mtd: nand_bbt: introduce independent nand BBT

Hello,

On 13 March 2016 at 23:47, Peter Pan <peterpansjtu@...il.com> 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/<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>
>

You mention this structure, but nothing in the current patchset is actually
enforcing it. This is more the future direction we are going.

> Most of the patch is borrowed from Brian Norris <computersforpeace@...il.com>.
> 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.

Thanks!
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar