From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagan Teki Date: Thu, 13 Dec 2018 02:15:16 +0530 Subject: [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM In-Reply-To: <20181212214035.43b825b3@bbrezillon> References: <20181212173228.12281-1-vigneshr@ti.com> <20181212173228.12281-4-vigneshr@ti.com> <20181212214035.43b825b3@bbrezillon> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Dec 13, 2018 at 2:10 AM Boris Brezillon wrote: > > Hi Jagan, > > On Thu, 13 Dec 2018 01:55:08 +0530 > Jagan Teki wrote: > > > On Wed, Dec 12, 2018 at 11:08 PM Vignesh R wrote: > > > > > > Add non DM version of SPI_MEM to support easy migration to new SPI NOR > > > framework. This can be removed once DM_SPI conversion is complete. > > > > Our intention to use new driver to follow dm, why we need to support > > non-dm? any usecases? > > Looks like we're having the same discussion over and over. Vignesh is > dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if > we want to keep everyone happy while getting rid of some legacy code, > that's the only solution. DM conversion is a nice goal, but it's kind > of orthogonal to what Vignesh is working on. If DM_SPI conversion > happens before the spi-nor stuff is merged (which I doubt) then this > patch can simply be dropped. spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)