[PATCH v6 00/15] A SPI NAND framework under generic NAND framework

[Peter Pan 潘栋 (peterpandong)]

Hi Boris,

在 2017年12月4日，22:05，Boris Brezillon <boris.brezillon at free-electrons.com<mailto:boris.brezillon at free-electrons.com>> 写道：

Hi Frieder,

On Mon, 4 Dec 2017 14:32:14 +0100
Frieder Schrempf <frieder.schrempf at exceet.de<mailto:frieder.schrempf at exceet.de>> wrote:

Hi Boris,

If everything goes well, we should be good for 4.14, and the patches
will have spent enough time in linux-next to discover obvious bugs.

What is the latest status of the SPI-NAND framework patches?

The reason I am asking is, that we have hardware based on the NXP
i.MX6UL SOC with a serial NAND connected via QSPI interface.

We currently have a working implementation based on a 3.14 vendor kernel
using a modified version of the "mt29f_spinand" staging driver, but for
the future we plan to use a recent mainline kernel.

We also think about porting our implementation to the new framework to
enable support for more SPI NAND chips (Winbond, Toshiba) and for the
NXP QSPI-controller.

Therefore we would like to know about the current schedule for bringing
the framework to mainline.

Sorry for the silence and the lack of progress on this front. I don't
have much time to work on this SPI-NAND framework (I do it on my spare
time), and last time I had a look and tried to address my own comments
on Peter's version, I realized I was not really happy with the
implementation, mainly because it copies some of the mistakes done in
the raw/parallel NAND framework.
So I ended up rewriting a lot of code, and didn't have time to test the
new implementation [1].

I’m still waiting for your git branch for spi NAND. Is this the branch I’m waiting for? I just took a quick look at it and I found you put more common code into new Nand core. This is cool. I thought we will do this job after spi NAND being merged. Anyway, do you want both spi and raw NAND code to be rebased on new NAND core or we just put spi NAND in? Anything I can help to speed the spi NAND merge up?

Thanks
Peter Pan


Note that it's mainly a rewrite of the generic NAND layer the SPI-NAND
framework is based on. I also re-considered the option of moving
existing BBT handling code in the generic layer, because again, I think
we should try to lighten the existing implementation instead of
quickly adapting it to the generic NAND layer. So, what's in [1] is
basic SPI-NAND support without BBT and ECC. Of course, this will be
extended later on, but I think we should start small, and take the time
to think about how we want to extend the generic layer so that some of
the code can be re-used by the parallel/raw NAND and OneNAND frameworks.

I'm really sorry to have blocked this initiative by not responding
and/or not spending the necessary time to rework the code, but I
really think we should have a strong base if we don't want to end up
with what he have in the parallel/raw NAND/OneNAND frameworks (a code
base that is hardly maintainable, with a lot of code duplication).

Anyway, any help is appreciated, so if you do have time to
review/test/enhance this code, feel free to do it.

Regards,

Boris

[1]https://github.com/bbrezillon/linux-0day/commits/nand/spi-nand