From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Sun, 11 Oct 2015 15:47:30 -0600 Subject: [U-Boot] [PATCH v2] dm: implement a cfi flash uclass In-Reply-To: <561A643E.5000301@wytron.com.tw> References: <1444289667-23775-1-git-send-email-thomas@wytron.com.tw> <1444548628-10119-1-git-send-email-thomas@wytron.com.tw> <561A23CE.6090900@wytron.com.tw> <561A54E2.9050803@wytron.com.tw> <561A643E.5000301@wytron.com.tw> 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 11 October 2015 at 07:29, Thomas Chou wrote: > Hi Bin, > > On 10/11/2015 08:43 PM, Bin Meng wrote: >> >> The spi-flash is converted to driver model, which is good, as there >> are spi flashes from different vendors which have different op codes >> thus need different drivers to handle. But for cfi-flash, almost every >> cfi-flash we see in the market conforms to the same CFI spec, thus we >> only need one driver (drivers/mtd/cfi_flash.c) to work with all these >> flashes, right? Unless I am missing something recently, eg: some >> vendors started to created flashes which are not 100% compatible with >> the CFI spec? If this is the only single driver, I don't see the need >> to create a special driver model uclass for it. Just an open >> discussion. I am not saying we should, or we should not :) > > > I had the same question myself. But I found that there are several uclasses > which has only one driver. No worries. :) I don't see any problem with this in general, although the point with CFI is that you are really implementing the uclass, as there will not going to be any drivers (as I understand it). Looking at SPI flash, it does have an API (read, write, erase). Could CFI use the same API? That might mean that we could unify the two and share a uclass. One approach may be to use a name like UCLASS_FLASH, and add some operations to it. Then we can say that we have a real uclass. The operations could come in a separate flash perhaps. > >>> It is not just base address. There is device binding with compatible ids. >>> There will be resources allocation, too. Please don't limit your >>> imagination >>> by my poor coding skill. >> >> >> All there can be obtained from device tree. Being a non-DM driver does >> not prevent you from using device tree. > > > It is true. Yet using driver model does have some advantages over non-DM. It > is more unified and dynamic. So I chose the DM way when I have to add device > tree binding. You may find my patch quite trivial. Thanks to the DM > framework. Regards, Simon