[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54ADF90B.1070800@imgtec.com>
Date: Thu, 8 Jan 2015 00:27:07 -0300
From: Ezequiel Garcia <ezequiel.garcia@...tec.com>
To: "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>,
"Peter Pan 潘栋 (peterpandong)"
<peterpandong@...ron.com>
Subject: Re: [PATCH 0/3] An alternative to SPI NAND
Hi Qi Wang,
On 01/07/2015 11:45 PM, Qi Wang 王起 (qiwang) wrote:
> Hi Brian,
>
> On Thu, Jan 08, 2015 at 9:03:24AM +0000, Brian Norris wrote:
>>
>> On Thu, Jan 08, 2015 at 12:47:24AM +0000, Peter Pan 潘栋 (peterpandong)
>> wrote:
>>> Documentation/devicetree/bindings/mtd/spi-nand.txt | 22 +
>>> drivers/mtd/Kconfig | 2 +
>>> drivers/mtd/Makefile | 1 +
>>> drivers/mtd/spi-nand/Kconfig | 7 +
>>> drivers/mtd/spi-nand/Makefile | 3 +
>>> drivers/mtd/spi-nand/spi-nand-base.c | 2034
>> ++++++++++++++++++++
>>> drivers/mtd/spi-nand/spi-nand-bbt.c | 1279 ++++++++++++
>>
>> I can already tell by the diffstat that I don't like this. We probably
>> don't need 3000 new lines of code for this, but we especially don't want
>> to duplicate nand_bbt.c. It won't take a lot of work to augment
>> nand_bbt.c to make it shareable. (I can whip that patch up if needed.)
>
> Yes, I agree with you, Nand_bbt.c do can be shared by Parallel NAND and
> SPI NAND. Actually, we are working at this now. Will send patches to you
> Once we finished it.
>
Thanks for the quick submission!
However, Brian is right, this code duplication is a no go.
Perhaps a more valid approach would be to first identify the code that
needs to be shared in nand_bbt.c and nand_base.c, and export those
symbols (or maybe do the required refactor).
Then, separate the SPI NAND upper and lower logic (in a similar to my
proposal, which I still consider turned out to be clean).
These two things would lead to a simpler and smaller patchset. I also
suggest to cut off everything that we don't utterly need on a first
submission, so it's easier to review.
--
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