Hi Jagan,

On Fri, Nov 27, 2015 at 2:54 AM, Jagan Teki jteki@openedev.com wrote:

Hi Simon,

Some how I'm unclear about your comments in previous series probably I my misunderstanding or something. let me explain about my plan on spi-nor development.

The entire spi-flash code is generic for all means there is no separate code for any platform or device. So I call it as spi-flash core. spi-flash core having functionaries like read_jedec, flash read/write/erase all these were calling from cmd_sf using dm and non-dm version, here I'm replacing this MTD since it is core interface it doesn't handle any specific device or uclass and mtd operations are being used directly without any dm except the probe.

So spi-flash shouldn't need dm and the respective probe sf_probe will follow dm as it allocates spi_flash and by taking spi_slave{} setup spi-uclass. spi-flash operation are common and there is no different ops for different drivers or devices or something and mtd_ops are manged directly from cmd_sf like nand and spi-nor in Linux.

And once core sits stable spi-flash will implemented as spi-nor core and the bellowed drivers becomes spi-nor drivers like spi-nor to spi driver interface and spi-nor controller drivers these are dm-driven it's having dm ops similar to spi-flash ops and spi-flash no where required.

My understanding is that when we introduce a new driver feature, it should target driver model by default. This is to encourage boards to take advantage of driver model, and all these *new* features. This is what Simon asked for. As Simon mentioned, probably we should make the SPI flash DM conversion complete now instead of adding any new feature on top of it.

cmd_sf

MTD

spi-nor or spi-flash

"spi-nor to spi drivers" and spi-nor controller driver

[snip]

Regards, Bin