RFC SPI-NAND support

Hi Jagan,

Quoted 13 lines · Jagan Teki

+ Boris
+ Suneel (who helped in DM MTD)
+ Siva, Michal (zynq qspi)

Quoted 7 lines · Miquel Raynal

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.

Quoted 2 lines

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

Quoted 3 lines

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/

Quoted 3 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 4 lines

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