[U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM

[Boris Brezillon]

On Thu, 13 Dec 2018 04:40:30 +0530
Jagan Teki <jagan at amarulasolutions.com> wrote:

> 
> I do really understand your intention about the real question.
> - Any code or generic code will add in U-Boot should be driver-model
> driven, are you agree this point?
>   Yes- thanks.
>   No - we need to have separate discussion.

Depends on what you mean by driver-model driven. Yes, applying the DM
sometimes makes sense, but blindly trying to push it everywhere just for
the sake of being "DM compliant" is a huge mistake IMO. One example of
the thing you suggested which didn't make sense at all: force MTD users
to manipulate udevice objects instead of mtd_info ones.

> 
> Any code that related to spi, or spi-flash should be driver-model
> driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor
> changes resist for long time to fit).

You seem to use the term "driver-model" a lot without clearly
explaining what you have in mind. The driver-model should be used
where it makes sense, but some of your suggestions don't make any sense
to me. Like the proposal to add a SPI NOR uclass while we already have
an MTD uclass which works just fine for all kind of flash devices.

Oh, and this strict rule that says "don't provide wrappers to handle
non-DM compliant cases" is just wrong. As I said, none of these dummy
wrappers prevent you from enforcing DM_SPI conversion, and it allows
us to support existing HW while getting rid of the old code base. Plus,
I suggested to declare the spi-nor driver as an MTD uclass so it's
not like we're completely ignoring your comments :P.