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

[Boris Brezillon <boris.brezillon@free-electrons.com>]

Hi Frieder,

On Mon, 4 Dec 2017 14:32:14 +0100
Frieder Schrempf <frieder.schrempf@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].

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