From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Fri, 4 Jan 2019 14:28:55 -0700 Subject: [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM In-Reply-To: References: <20181212173228.12281-1-vigneshr@ti.com> <20181212173228.12281-4-vigneshr@ti.com> <20181212214035.43b825b3@bbrezillon> <20181212220205.4ad00b36@bbrezillon> <20181212222508.5c79d762@bbrezillon> <20181213005514.3b9de371@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 Hi, On Fri, 14 Dec 2018 at 03:00, Jagan Teki wrote: > > On Thu, Dec 13, 2018 at 5:25 AM Boris Brezillon > wrote: > > > > On Thu, 13 Dec 2018 04:40:30 +0530 > > Jagan Teki wrote: > > > > > > > > I do really understand your intention about the real question. > > > - Any code or generic code will add in U-Boot should be driver-model > > > driven, are you agree this point? > > > Yes- thanks. > > > No - we need to have separate discussion. > > > > Depends on what you mean by driver-model driven. Yes, applying the DM > > sometimes makes sense, but blindly trying to push it everywhere just for > > the sake of being "DM compliant" is a huge mistake IMO. One example of > > the thing you suggested which didn't make sense at all: force MTD users > > to manipulate udevice objects instead of mtd_info ones. > > (+ Simon) > ie How we proceed when DM is introduced in U-Boot. May be you can ask > Simon or Other DM fellow developers if my statement doesn't make sense > to you. ie whole reason of spi-nor changes last for year. I generally prefer to use DM fully. I am not sure what an mtd_info is if it isn't a device. > > > > > > > > > Any code that related to spi, or spi-flash should be driver-model > > > driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor > > > changes resist for long time to fit). > > > > You seem to use the term "driver-model" a lot without clearly > > explaining what you have in mind. The driver-model should be used > > where it makes sense, but some of your suggestions don't make any sense > > to me. Like the proposal to add a SPI NOR uclass while we already have > > an MTD uclass which works just fine for all kind of flash devices. > > You better read the thread carefully. read what I'm saying on the thread[1] > > " So, if no driver should be part of spi-nor and all can be handle > spi-mem even-though they have controller specific features, yes we can > skip SPI_NOR_UCLASS otherwise we need spi-nor uclass that can be child > uclass of MTD" > > Did it state insisting SPI-NOR uclass, I was clearly giving if condition here. > > [1] https://patchwork.ozlabs.org/cover/1007589/ Regards, Simon