[U-Boot] [PATCH v6 00/31] SPI-NAND support

[Miquel Raynal]

Hi Tom, Jagan,

Boris Brezillon <boris.brezillon at bootlin.com> wrote on Thu, 16 Aug 2018
18:58:58 +0200:

> Tom, Jagan,
> 
> On Thu, 16 Aug 2018 17:29:58 +0200
> Miquel Raynal <miquel.raynal at bootlin.com> wrote:
> 
> > During the last months, Boris Brezillon shared his work to support
> > serial flashes within Linux. First, he delivered (and merged) a new
> > layer called spi-mem. He also initiated in Linux MTD subsystem the move
> > of all 'raw' NAND related code to a raw/ subdirectory, adding at the
> > same time a NAND core that would be shared with all NAND devices. Then,
> > he contributed a generic SPI-NAND driver, making use of this NAND core,
> > as well as some vendor code to drive a few chips.
> > 
> > On top of this work, I made some cleanups in the MTD layer and added an
> > 'mtd' U-Boot command to handle all sort of MTD devices. This should
> > become the default command instead of having one per flash flavor
> > ('sf', 'nand', 'spi-nand' ?).
> > 
> > The series has been tested on an Ocelot board PCB123 (VSC7514),
> > featuring a Macronix SPI NAND chip.
> > 
> > TL;DR: the series contains:
> > - A few patches from Linux to resynchronize some areas of the MTD layer.
> > - Various fixes and re-organization of the MTD subsystem.
> > - The introduction of the SPI-mem interface.
> > - The addition of the generic SPI-NAND driver (and its bindings).
> > - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> > - A new 'mtd' command.
> > - Support for spi-nand devices in mtdparts.
> > 
> > To test your SPI-NAND device with U-Boot simply follow these lines:
> >   
> > > setenv mtdparts mtdparts=spi-nand0:1m(foo),-(bar)
> > > ubi part bar         # create a static UBI volume in the bar partition
> > > mtd list             # show the current MTD devices/partitions    
> > 
> > Thanks,
> > Miquèl
> >   
> 
> [...]
> 
> Can we get some of those patches merged to avoid sending another
> version containing more than 30 patches. Here is a list of patches which
> IMO are ready to be merged:
> 
>  - 1 to 4
>  - 5 and 6 if 6 is squashed in 5
>  - 7 to 23
> 

Yes, I agree with Boris, I do not want to resend another 30+ patch
series while the changes are on the last 5 only, could one of you
please apply them from 1 to 23 (with 6 squashed in 5) ?

Next week I will send a v7 for patches 24..31.

Thanks,
Miquèl