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

[Jagan Teki <jagan@amarulasolutions.com>]

On Tue, May 26, 2020 at 5:11 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, May 25, 2020 at 03:48:22PM -0600, Simon Glass wrote:
> > Hi Jagan,
> >
> > On Mon, 25 May 2020 at 02:14, Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, May 22, 2020 at 10:20 PM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Jagan,
> > > >
> > > > On Fri, 22 May 2020 at 08:41, Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Fri, May 22, 2020 at 7:55 PM Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > Hi Jagan,
> > > > > >
> > > > > > On Thu, 14 May 2020 at 12:09, Jagan Teki <jagan@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@chromium.org>
> > > > > > > Cc: Vignesh R <vigneshr@ti.com>
> > > > > > > Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
> > > > > > > Signed-off-by: Jagan Teki <jagan@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.
> > >
> > > As I clearly mentioned in the commit message, there is no dm code
> > > being removed as such all I'm doing is to refactor the code to have
> > > two functional flows for dm and nodm. This would make the removal of
> > > non dm and developing the dm code specially on the MTD/SPI-NOR side
> > > become easy and meaningful.
> > > Most of nondm spi flash code is not that easy since it has SPL
> > > foot-print issues,and most of MTD code requires close attention as a
> > > lot of code is copied/synced from Linux.
> >
> > Then I think I am a bit lost. It sounds like you are saying you cannot
> > migrate to DM?
>
> I think we need to tie together 2 threads.  There are SPI drivers that
> are DM migrated for full U-Boot but cannot do the whole DM+DT thing in
> SPL.

Yes can have few drivers to left over, like 3 or 4 maximum, but as I
have mentioned in another thread may be having a direct SPI SPL driver
for these platforms will certainly finish the job as of now. Ex:
spl_spi_sunxi.c

Jagan.