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

Message ID 20200514180941.21542-2-jagan@amarulasolutions.com
State New
Headers show
Series
  • [1/2] mtd: spi: Separate dm vs nodm SF code
Related show

Commit Message

Jagan Teki May 14, 2020, 6:09 p.m.
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(-)

Comments

Simon Glass May 22, 2020, 2:24 p.m. | #1
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.

Regards,
Simon
Tom Rini May 22, 2020, 2:30 p.m. | #2
On Fri, May 22, 2020 at 08:24:58AM -0600, Simon Glass 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.

Yes.  I'm currently trying to come up with a series that drops MMC/USB
that haven't migrated as that's a full year past the build warning
deadline we set.  It won't go in for v2020.07 but it will go in for
right after.
Jagan Teki May 22, 2020, 2:40 p.m. | #3
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.

Jagan.
Simon Glass May 22, 2020, 4:50 p.m. | #4
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
Tom Rini May 22, 2020, 5:27 p.m. | #5
On Fri, May 22, 2020 at 10:50:35AM -0600, Simon Glass 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.

I strongly agree.  We're about to be a full year past the build warning
of "this will be removed".  I had even started by including SPI stuff in
my "drop these boards" local series but ran in to enough problems being
exposed I started with just the BLK related stuff.  So please, lets
start with disabling in or entirely removing defconfigs that are
tripping up the SPI migration warning.
Jagan Teki May 25, 2020, 8:14 a.m. | #6
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.

Jagan.
Simon Glass May 25, 2020, 9:48 p.m. | #7
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?

Regards,
Simon
Tom Rini May 25, 2020, 11:41 p.m. | #8
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 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?

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.
Jagan Teki May 26, 2020, 12:35 p.m. | #9
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.
Jagan Teki May 26, 2020, 12:40 p.m. | #10
On Tue, May 26, 2020 at 5:11 AM Tom Rini <trini at 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 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?
>
> 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.

Patch

diff --git a/cmd/sf.c b/cmd/sf.c
index 302201c2b0..3835dd857d 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -87,12 +87,7 @@  static int do_spi_flash_probe(int argc, char * const argv[])
 	unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
 	unsigned int mode = CONFIG_SF_DEFAULT_MODE;
 	char *endp;
-#ifdef CONFIG_DM_SPI_FLASH
-	struct udevice *new, *bus_dev;
-	int ret;
-#else
 	struct spi_flash *new;
-#endif
 
 	if (argc >= 2) {
 		cs = simple_strtoul(argv[1], &endp, 0);
@@ -120,22 +115,6 @@  static int do_spi_flash_probe(int argc, char * const argv[])
 			return -1;
 	}
 
-#ifdef CONFIG_DM_SPI_FLASH
-	/* Remove the old device, otherwise probe will just be a nop */
-	ret = spi_find_bus_and_cs(bus, cs, &bus_dev, &new);
-	if (!ret) {
-		device_remove(new, DM_REMOVE_NORMAL);
-	}
-	flash = NULL;
-	ret = spi_flash_probe_bus_cs(bus, cs, speed, mode, &new);
-	if (ret) {
-		printf("Failed to initialize SPI flash at %u:%u (error %d)\n",
-		       bus, cs, ret);
-		return 1;
-	}
-
-	flash = dev_get_uclass_priv(new);
-#else
 	if (flash)
 		spi_flash_free(flash);
 
@@ -145,7 +124,6 @@  static int do_spi_flash_probe(int argc, char * const argv[])
 		printf("Failed to initialize SPI flash at %u:%u\n", bus, cs);
 		return 1;
 	}
-#endif
 
 	return 0;
 }
diff --git a/drivers/mtd/spi/sf-uclass.c b/drivers/mtd/spi/sf-uclass.c
index 97a3f5d2c7..4993f7cd02 100644
--- a/drivers/mtd/spi/sf-uclass.c
+++ b/drivers/mtd/spi/sf-uclass.c
@@ -29,50 +29,38 @@  int spi_flash_erase_dm(struct udevice *dev, u32 offset, size_t len)
 	return log_ret(sf_get_ops(dev)->erase(dev, offset, len));
 }
 
-/*
- * TODO(sjg at chromium.org): This is an old-style function. We should remove
- * it when all SPI flash drivers use dm
- */
-struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
-				  unsigned int max_hz, unsigned int spi_mode)
-{
-	struct udevice *dev;
-
-	if (spi_flash_probe_bus_cs(bus, cs, max_hz, spi_mode, &dev))
-		return NULL;
-
-	return dev_get_uclass_priv(dev);
-}
-
 void spi_flash_free(struct spi_flash *flash)
 {
 	device_remove(flash->spi->dev, DM_REMOVE_NORMAL);
 }
 
-int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int cs,
-			   unsigned int max_hz, unsigned int spi_mode,
-			   struct udevice **devp)
+struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
+				  unsigned int max_hz, unsigned int spi_mode)
 {
 	struct spi_slave *slave;
-	struct udevice *bus;
+	struct udevice *new, *bus_dev;
 	char *str;
 	int ret;
 
+	/* Remove the old device, otherwise probe will just be a nop */
+	ret = spi_find_bus_and_cs(bus, cs, &bus_dev, &new);
+	if (!ret)
+		device_remove(new, DM_REMOVE_NORMAL);
+
 #if defined(CONFIG_SPL_BUILD) && CONFIG_IS_ENABLED(USE_TINY_PRINTF)
 	str = "spi_flash";
 #else
 	char name[30];
 
-	snprintf(name, sizeof(name), "spi_flash@%d:%d", busnum, cs);
+	snprintf(name, sizeof(name), "spi_flash@%d:%d", bus, cs);
 	str = strdup(name);
 #endif
-	ret = spi_get_bus_and_cs(busnum, cs, max_hz, spi_mode,
-				  "spi_flash_std", str, &bus, &slave);
+	ret = spi_get_bus_and_cs(bus, cs, max_hz, spi_mode,
+				 "spi_flash_std", str, &bus_dev, &slave);
 	if (ret)
-		return ret;
+		return NULL;
 
-	*devp = slave->dev;
-	return 0;
+	return dev_get_uclass_priv(slave->dev);
 }
 
 static int spi_flash_post_bind(struct udevice *dev)
diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c
index 8ab1816395..811d1cd4fa 100644
--- a/drivers/net/fm/fm.c
+++ b/drivers/net/fm/fm.c
@@ -383,20 +383,10 @@  int fm_init_common(int index, struct ccsr_fman *reg)
 		addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
 		int ret = 0;
 
-#ifdef CONFIG_DM_SPI_FLASH
-		struct udevice *new;
-
-		/* speed and mode will be read from DT */
-		ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS,
-					     CONFIG_ENV_SPI_CS, 0, 0, &new);
-
-		ucode_flash = dev_get_uclass_priv(new);
-#else
 		ucode_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
 					      CONFIG_ENV_SPI_CS,
 					      CONFIG_ENV_SPI_MAX_HZ,
 					      CONFIG_ENV_SPI_MODE);
-#endif
 		if (!ucode_flash) {
 			printf("SF: probe for ucode failed\n");
 		} else {
@@ -470,18 +460,8 @@  int fm_init_common(int index, struct ccsr_fman *reg)
 	void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
 	int ret = 0;
 
-#ifdef CONFIG_DM_SPI_FLASH
-	struct udevice *new;
-
-	/* speed and mode will be read from DT */
-	ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
-				     0, 0, &new);
-
-	ucode_flash = dev_get_uclass_priv(new);
-#else
 	ucode_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
 			CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
-#endif
 	if (!ucode_flash)
 		printf("SF: probe for ucode failed\n");
 	else {
diff --git a/env/sf.c b/env/sf.c
index af59c8375c..253f467832 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -35,21 +35,6 @@  static struct spi_flash *env_flash;
 
 static int setup_flash_device(void)
 {
-#ifdef CONFIG_DM_SPI_FLASH
-	struct udevice *new;
-	int	ret;
-
-	/* speed and mode will be read from DT */
-	ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
-				     CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE,
-				     &new);
-	if (ret) {
-		env_set_default("spi_flash_probe_bus_cs() failed", 0);
-		return ret;
-	}
-
-	env_flash = dev_get_uclass_priv(new);
-#else
 	struct spi_flash *new;
 
 	if (env_flash)
@@ -62,7 +47,7 @@  static int setup_flash_device(void)
 		env_set_default("spi_flash_probe() failed", 0);
 		return -EIO;
 	}
-#endif
+
 	return 0;
 }
 
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 3b33b970ef..c270c6eff7 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -75,17 +75,6 @@  int spi_flash_write_dm(struct udevice *dev, u32 offset, size_t len,
  */
 int spi_flash_erase_dm(struct udevice *dev, u32 offset, size_t len);
 
-int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int cs,
-			   unsigned int max_hz, unsigned int spi_mode,
-			   struct udevice **devp);
-
-/* Compatibility function - this is the old U-Boot API */
-struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
-				  unsigned int max_hz, unsigned int spi_mode);
-
-/* Compatibility function - this is the old U-Boot API */
-void spi_flash_free(struct spi_flash *flash);
-
 static inline int spi_flash_read(struct spi_flash *flash, u32 offset,
 				 size_t len, void *buf)
 {
@@ -112,10 +101,6 @@  int sandbox_sf_bind_emul(struct sandbox_state *state, int busnum, int cs,
 void sandbox_sf_unbind_emul(struct sandbox_state *state, int busnum, int cs);
 
 #else
-struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
-		unsigned int max_hz, unsigned int spi_mode);
-
-void spi_flash_free(struct spi_flash *flash);
 
 static inline int spi_flash_read(struct spi_flash *flash, u32 offset,
 		size_t len, void *buf)
@@ -154,6 +139,11 @@  static inline int spi_flash_erase(struct spi_flash *flash, u32 offset,
 }
 #endif
 
+struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
+				  unsigned int max_hz, unsigned int spi_mode);
+
+void spi_flash_free(struct spi_flash *flash);
+
 static inline int spi_flash_protect(struct spi_flash *flash, u32 ofs, u32 len,
 					bool prot)
 {