| Message ID | 20200514180941.21542-2-jagan@amarulasolutions.com |
|---|---|
| State | New |
| Headers | show |
| Series |
|
| Related | show |
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. Regards, Simon
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@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. 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.
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. Jagan.
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. Regards, Simon
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@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. 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.
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. Jagan.
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? Regards, Simon
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.
On Tue, May 26, 2020 at 3:18 AM Simon Glass <sjg@chromium.org> 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? No, we can. I have already started to make the possible drivers to switch. Will pause this patch as of now. Jagan.
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.
On Thu, May 14, 2020 at 11:39 PM 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> > --- I'm moving with this since we still have few drivers left for nondm code for SPL. Jagan.
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@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) {
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(-)