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

[Jagan Teki]

On Thu, Dec 13, 2018 at 5:25 AM Boris Brezillon
<boris.brezillon at bootlin.com> wrote:
>
> 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.

(+ Simon)
ie How we proceed when DM is introduced in U-Boot. May be you can ask
Simon or Other DM fellow developers if my statement doesn't make sense
to you. ie whole reason of spi-nor changes last for year.

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

You better read the thread carefully.  read what I'm saying on the thread[1]

" So, if no driver should be part of spi-nor and all can be handle
spi-mem even-though they have controller specific features, yes we can
skip SPI_NOR_UCLASS otherwise we need spi-nor uclass that can be child
uclass of MTD"

Did it state insisting SPI-NOR uclass, I was clearly giving if condition here.

[1] https://patchwork.ozlabs.org/cover/1007589/