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

[Miquel Raynal]

Hello,

Miquel Raynal <miquel.raynal at bootlin.com> wrote on Fri, 17 Aug 2018
10:38:46 +0200:

> 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.

I am almost ready to send a new iteration for the last set of patches,
can I have your feedback on the first set (up to 23)?

Thanks,
Miquèl