[PATCH 2/2] sf: Simplify probe for dm code

[Simon Glass]

Hi Jagan,

On Fri, 22 May 2020 at 08:41, Jagan Teki <jagan at amarulasolutions.com> wrote:
>
> Hi Simon,
>
> On Fri, May 22, 2020 at 7:55 PM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Jagan,
> >
> > On Thu, 14 May 2020 at 12:09, Jagan Teki <jagan at amarulasolutions.com> wrote:
> > >
> > > Handling probing code for a particular uclass between
> > > dm vs nodm always confusing and requires additional
> > > ifdefs to handle them properly.
> > >
> > > But, having separate low-level code bases for dm and
> > > nodm can make it easy for the command level to use same
> > > function name to probe the devices. This would indeed
> > > avoid extra ifdef call in source code.
> > >
> > > So, this patch probes the spi flash in common legacy
> > > call spi_flash_probe for both dm and nodm devices and
> > > give a chance to handle on respective code bases based
> > > on the build files.
> > >
> > > Cc: Simon Glass <sjg at chromium.org>
> > > Cc: Vignesh R <vigneshr at ti.com>
> > > Cc: Daniel Schwierzeck <daniel.schwierzeck at gmail.com>
> > > Signed-off-by: Jagan Teki <jagan at amarulasolutions.com>
> > > ---
> > >  cmd/sf.c                    | 22 ---------------------
> > >  drivers/mtd/spi/sf-uclass.c | 38 +++++++++++++------------------------
> > >  drivers/net/fm/fm.c         | 20 -------------------
> > >  env/sf.c                    | 17 +----------------
> > >  include/spi_flash.h         | 20 +++++--------------
> > >  5 files changed, 19 insertions(+), 98 deletions(-)
> >
> > +Tom Rini
> >
> > This is really going the wrong way. You would cement the code in limbo
> > forever and no one would be able to migrate property.
> >
> > Instead, you should add a patch to disable SPI flash on boards which
> > have not migrated. Then we can actually clean up the mess properly.
> >
> > The deadline has passed and people have had more than 5 years to migrate.
> >
> > It is time to make the cut.
>
> It's not entirely about migration, but also the future development
> with MTD uclass. I'm trying to separate the code for dm vs nodm, and
> dm files would be further developed to use MTD uclass (series will
> send soon) and nodm keep it as static and drop at a later point. I
> take the clean part early before moving into MTD uclass since the
> migration from SPI flash to MTD is smooth.

To me it looks like the DM way is being removed.

I really feel this should be done in the reverse order. Remove the old
code and then refactor.

The old code does not understand DT at all. It means we are stuck with
things like CONFIG variables for the bus to use for SPI environment,
etc.

Please let's just migrate. It is *well* past time.

Regards,
Simon