Re: [PATCH 0/3] An alternative to SPI NAND

[Ezequiel Garcia <ezequiel.garcia@imgtec.com>]

On 01/20/2015 11:11 PM, Qi Wang 王起 (qiwang) wrote:
> On 01/20/2015 6:36 PM, Ezequiel Garcia wrote:
>>
>> On 01/12/2015 12:10 PM, Qi Wang 王起 (qiwang) wrote:
>>> Hi Ezequiel,
>>>
>>> On 01/08/2015 11:27 AM, Ezequiel Garcia wrote:
>>>>
>>>> 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).
>>>
>>> Yes, I agree Brian's suggestion in another mail.
>>>
>>> " The BBT code is something we definitely want to share, but it's
>> actually
>>> not very closely tied to nand_base.c, and it looks pretty easy to adapt
>>> to any MTD that implements mtd_read_oob()/mtd_write_oob(). We'd just
>>> need to parameterize a few relevant device details into a new nand_bbt
>>> struct, rather than using struct nand_chip directly."
>>>
>>> To abstract a new nand_bbt struct instead of nand_chip to make SPI NAND
>>> and parallel NAND can share nand_bbt.c file, I already begin to work on
>>> this.
>>>
>>> For code shared in nand_base.c, I agree it would be better if we can find
>>> a good method to share nand_base.c code between spi nand and parallel
>> nand.
>>> But frankly speaking, I'm not satisfied for the remap command method.
>> This
>>> method make code difficult to maintain when SPI NAND and Parallel NAND
>>> evolve much differently in the future.
>>>
>>> Take some example,
>>> If one new command (cache operation, multiple plane operation)
>> implemented
>>> in parallel NAND code, and is used in nand_read or nand_write, that will
>>> cause maintainer to modify SPI NAND code to remap this new command,
>> though
>>> this modification probably could be slight. That means modification on
>>> Parallel NAND flash need to consider SPI NAND as well.
>>>
>>> How do you think about this?
>>>
>>> For Peter Pan's patchset, if we do some modification to make nand_bbt.c
>> to
>>> make it shareable for Parallel and SPI NAND. The code line should be 2000.
>>> I believe I can review this spi-nand-base.c to remove some redundant code
>>> that may hundreds line. Is 1700 or 1800 code line is more acceptable?
>>>
>>> Let me know your opinions.
>>>
>>
>> Sounds good.
>>
>> Do you still plan to maintain the spi-nand-base.c and spi-nand-device.c
>> separation?	
> 
> Yes, still plan to maintain the spi-nand-base.c and spi-nand-device.c
> separation. Abstract common code to spi-nand-base.c, and spi-nand-device.c is
> used for realize the different function for different SPI NAND, such as ecc
> layout, read ID etc.
> 

Any news about this? Is there anything I can do to help (reviewing,
testing, coding...)?

Thanks!
-- 
Ezequiel