[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160329100716.187b0bcc@bbrezillon>
Date: Tue, 29 Mar 2016 10:07:16 +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, xuejiancheng@...wei.com,
Peter Pan <peterpandong@...ron.com>
Subject: Re: [PATCH 05/11] mtd: nand: use new BBT API instead of old ones
On Mon, 28 Mar 2016 16:12:08 +0800
Peter Pan <peterpansjtu@...il.com> wrote:
> On Fri, Mar 25, 2016 at 4:51 PM, Boris Brezillon
> <boris.brezillon@...e-electrons.com> wrote:
> > On Mon, 14 Mar 2016 02:47:58 +0000
> > Peter Pan <peterpansjtu@...il.com> wrote:
> >
> >> Use new BBT APIs (nand_bbt_*()) in NAND. Keep old APIs (nand_*_bbt())
> >> exist temporarily.
> >>
> >> Signed-off-by: Brian Norris <computersforpeace@...il.com>
> >> Signed-off-by: Peter Pan <peterpandong@...ron.com>
> >> ---
> >> drivers/mtd/nand/docg4.c | 7 +-
> >> drivers/mtd/nand/nand_base.c | 151 ++++++++++++++++++++++++++++++++++++++++---
> >> include/linux/mtd/nand.h | 15 ++++-
> >> 3 files changed, 160 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> >> index b6facac..6f0e3b9 100644
> >> --- a/drivers/mtd/nand/nand_base.c
> >> +++ b/drivers/mtd/nand/nand_base.c
> >
> > [...]
> >
> >> +static int nand_default_bbt(struct mtd_info *mtd)
> >> +{
> >> + struct nand_chip *chip = mtd_to_nand(mtd);
> >> + struct nand_bbt *nand_bbt = NULL;
> >> + struct nand_chip_layout_info *info =
> >> + kzalloc(sizeof(struct nand_chip_layout_info), GFP_KERNEL);
> >
> > No, this should be directly embedded in nand_chip, and should replace
> > the numchips/chipsize/... fields declared in there.
>
> As I said in patch 2, I keep it like this temporarily. Will embedded it in
> struct nand_chip later.
Hm, I don't like the idea of duplicating the same information in two
different places, just because we don't want to touch NAND drivers/core
code. I'll have a look, and if it's not too invasive (not sure we have
that much code using those fields), I'd prefer having them patched right
now...
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Powered by blists - more mailing lists