[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54CB6F51.2070403@imgtec.com>
Date: Fri, 30 Jan 2015 08:47:29 -0300
From: Ezequiel Garcia <ezequiel.garcia@...tec.com>
To: "Peter Pan 潘栋 (peterpandong)"
<peterpandong@...ron.com>,
"Qi Wang 王起 (qiwang)"
<qiwang@...ron.com>, Brian Norris <computersforpeace@...il.com>
CC: "dwmw2@...radead.org" <dwmw2@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"Frank Liu 刘群 (frankliu)"
<frankliu@...ron.com>,
"Melanie Zhang 张燕 (melaniezhang)" <melaniezhang@...ron.com>,
James Hartley <james.hartley@...tec.com>,
"Andrew Bresticker" <abrestic@...omium.org>
Subject: Re: [PATCH 0/3] An alternative to SPI NAND
On 01/29/2015 09:57 PM, Peter Pan 潘栋 (peterpandong) wrote:
[..]
>
> Currently, we are working on sharing the bbt code. I think your and Brain's suggestion
> will be very helpful.
>
> There are two options. We can put struct nand_bbt pointer in either nand_chip
> or mtd_info structure.
I'm sorry, you lost me here. Do you mean struct nand_bbt_descr ?
> If put nand_bbt in nand_chip, we need to change the
I thought the plan was NOT to base spi-nand on nand, so you can't put
this in nand_chip, can you?
Also: After looking at the nand_bbt.c file, I'm wondering how promising
is to separate it from NAND. It seems the BBT code is quite attached to
NAND!
Are you planning to do this in just one patch? Maybe it's better to
start simple and prepare small patches that gradually make the
nand_base.c and nand_bbt.c files less dependent.
For instance, you can get rid of the memory release in a first patch:
/* Free bad block table memory */
kfree(chip->bbt);
if (!(chip->options & NAND_OWN_BUFFERS))
kfree(chip->buffers);
/* Free bad block descriptor memory */
if (chip->badblock_pattern && chip->badblock_pattern->options
& NAND_BBT_DYNAMICSTRUCT)
kfree(chip->badblock_pattern);
by moving it to some nand_bbt_release() function.
I might be pushing some patches to do this, as I think it can be useful
in general to clean this code.
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists