[U-Boot] [PATCH v2] dm: implement a cfi flash uclass

From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] dm: implement a cfi flash uclass
Date: Sun, 11 Oct 2015 15:47:30 -0600	[thread overview]
Message-ID: <CAPnjgZ1=WD1K38m-vsxMV1-VXrwrB=LWXoGxa5ALRPDvA9r10A@mail.gmail.com> (raw)
In-Reply-To: <561A643E.5000301@wytron.com.tw>

Hi,

On 11 October 2015 at 07:29, Thomas Chou <thomas@wytron.com.tw> 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