From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bin Meng Date: Sun, 11 Oct 2015 20:43:12 +0800 Subject: [U-Boot] [PATCH v2] dm: implement a cfi flash uclass In-Reply-To: <561A54E2.9050803@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> 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 Thomas, On Sun, Oct 11, 2015 at 8:24 PM, Thomas Chou wrote: > Hi Bin, > > On 10/11/2015 05:10 PM, Bin Meng wrote: >> >> It's unlikely we are going to create another instance of cfi-flash >> driver, isn't it? Then it's just a single driver which does not make >> cfi-flash a "class". We can just update the cfi-flash driver to read >> its flash base address directly from device tree, without the need to >> go through driver model. > > > It is an on-going process to convert existing drivers to driver model. The > spi-flash has driver model now. How do you think it is unlikely that > cfi-flash should be converted to driver-model? 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 :) > > 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. > > There are three good things to u-boot in recent years, the Kconfig, device > tree control and driver model. Together, they provide more flexibility to > processors on FPGA, like nios2. Here almost everything is programmable, and > it is difficult to hard code driver setup in the old way. > > Huge thanks to all the contributors. Thank you too, Bin. > Agreed! Regards, Bin