[U-Boot] [PATCH v7 00/34] sf: MTD support

[Bin Meng]

Hi Jagan,

On Fri, Nov 27, 2015 at 2:54 AM, Jagan Teki <jteki at 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