[U-Boot] [RFC PATCH 00/20] SPI-NAND support

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Jagan,

On Thu, 7 Jun 2018 11:21:22 +0530, Jagan Teki
<jagannadh.teki@gmail.com> wrote:

> + Boris
> + Suneel (who helped in DM MTD)
> + Siva, Michal  (zynq qspi)
> 
> On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal <miquel.raynal@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.  
> 
> 1) Can you pointed us the Linux changes along with discussion thread
> about spi-mem, and spi-nand.

Sure, you can have a look there:

SPI-mem:
http://lists.infradead.org/pipermail/linux-mtd/2018-April/080225.html

SPI-NAND:
http://lists.infradead.org/pipermail/linux-mtd/2018-May/081005.html

> 
> 2) If my understanding was correct, spi-mem is replacement for spi-nor
> controller drivers from driver/mtd/spi-nor in Linux.

It is not 'exactly' a replacement for spi-nor controller drivers but
that's the idea. I suggest you to have a look at Boris' blog post about
it:
https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/

> 
> 3) If so is fsl_qspi spi-nor driver moves to drivers/spi area? yes
> then how does flash changes handled by spi-mem.

This series does not migrate the SPI-NOR stack to spi-mem. It focuses
on SPI-NAND for now. And I don't understand the second sentence.

> 
> 4) we have zynq qspi controller which has extensive features like dual
> flash(stacked and parallel) does spi-mem support these flash specific
> changes?

This controller is very specific and such support has not yet been
added.

> 
> 5) Better to send spi-mem and spi-nand changes separately, for better reviewing.

It would mean sending 3 or 4 distinct series, I thought better to give
the whole picture but that's your choice.

> 
> 6) We have DM MTD layer in ML, better to send the changes on-top [1]
> 
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=20450

This is great to see such effort being made to develop U-Boot
driver-model but is there a real need for yet another layer on top of
the MTD stack?

I'm looking at mtd-uclass.c for instance, I don't get the need for a
mtd_dread() function, all the operations in the mtd_d*() helpers are
already handled by mtd/mtdcore.c, no?

And the mtd_ops structure does not bring a lot. Should not we keep it
simple and avoid such intermediate layer?

Also, there is the introduction of a spinor command (what about the
existing 'sf'?), which is exactly the opposite of what the MTD
abstraction would told us to do (thus, the 'mtd' generic command).

Regards,
Miquèl