From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Chou Date: Sun, 11 Oct 2015 21:29:34 +0800 Subject: [U-Boot] [PATCH v2] dm: implement a cfi flash uclass In-Reply-To: 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: <561A643E.5000301@wytron.com.tw> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. :) >> 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. Best regards, Thomas