On Tue, May 26, 2020 at 3:18 AM Simon Glass <s...@chromium.org> wrote: > > Hi Jagan, > > On Mon, 25 May 2020 at 02:14, Jagan Teki <ja...@amarulasolutions.com> wrote: > > > > Hi Simon, > > > > On Fri, May 22, 2020 at 10:20 PM Simon Glass <s...@chromium.org> wrote: > > > > > > Hi Jagan, > > > > > > On Fri, 22 May 2020 at 08:41, Jagan Teki <ja...@amarulasolutions.com> > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > On Fri, May 22, 2020 at 7:55 PM Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > Hi Jagan, > > > > > > > > > > On Thu, 14 May 2020 at 12:09, Jagan Teki <ja...@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 <s...@chromium.org> > > > > > > Cc: Vignesh R <vigne...@ti.com> > > > > > > Cc: Daniel Schwierzeck <daniel.schwierz...@gmail.com> > > > > > > Signed-off-by: Jagan Teki <ja...@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.
