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

[Simon Glass]

Hi,

On Fri, 14 Dec 2018 at 03:00, Jagan Teki <jagan at amarulasolutions.com> wrote:
>
> 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.

I generally prefer to use DM fully. I am not sure what an mtd_info is
if it isn't a device.

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

Regards,
Simon