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

[Bin Meng]

Hi,

On Mon, Oct 12, 2015 at 5:47 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi,
>
> On 11 October 2015 at 07:29, Thomas Chou <thomas at 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. :)

These single drivers under a uclass is probably due to we have not
converted all other drivers to driver model yet.

>
> 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).

Yep, that's really my concern regarding to a new 'class' to be created
but actually no additional driver will use that 'class'.

>
> 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.

Yep, I believe this is a better approach.

>
> 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

Regards,
Bin