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

[Jagan Teki]

On Tue, May 26, 2020 at 3:18 AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Jagan,
>
> On Mon, 25 May 2020 at 02:14, Jagan Teki <jagan at amarulasolutions.com> wrote:
> >
> > Hi Simon,
> >
> > On Fri, May 22, 2020 at 10:20 PM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > 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.
> >
> > 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?

No, we can. I have already started to make the possible drivers to
switch. Will pause this patch as of now.

Jagan.