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