[RFC] Adding MTD to device tree

[Sergei Shtylyov]

Hello.

Segher Boessenkool wrote:

>>>   Required properties:
>>>    - device_type : one of "nand-flash", "nor-flash", or "rom".

    I thought about having the separate device types initially, then I decided 
that all the differences can be handled on the driver level...

>>There are more than just those kinds of MTDs.  There's dataflash,
>>AG-AND, NVRAM, ioremappable DRAM, etc.  I'd prefer it to just be  
>>called "flash".  See more below.

> Existing firmwares call it "rom", "nvram", "flash".  All of those
> are easy; and I have really no opinion how all the weirdo nand-flash
> etc. interfaces should be handled.

> device_type communicates to the device-tree consumer what other
> properties to expect in this node -- it does not indicate the exact
> programming model of the device itself.

    Erm, IIUC the exact set of properties is defined by the node name (or the 
"compatible" property). The device type defines some mandatory set of 
properties/methods but there may be some specific...

> I suspect for most nand-flash you can get away with a device_type
> of "nand-flash"; for some you might have to specify something more
> detailed.

    Hm, not sure that you need to be so much detailed with the device type.
The original OF spec. had device type "block" signifying any kind of blocked 
storage device.

>>>    - model : an identifier for the actual controller chip used.

>>Meaning what exactly?  Lots of NOR flash doesn't have a "controller".

> Lots of those chips from different vendors are pin-compatible as well,
> so you cannot really hardcode one specific model number.  I don't see
> this information being very useful anyway.  Instead, in most cases, the
> information you're really after is the programming interface for the
> device.  And that goes...

    This property might be marked optional still.

>>>    - compatible : Should be the name of the MTD driver. For
>>>      type "rom", this is most likely "physmap".

>>This I agree with, but Sergei already had this.  And since you're
>>specifying the name of the MTD driver, that typically already knows  
>>what
>>type of chip it's talking to.

> "compatible" contains a list, most specific first.  So for example
> for a NOR-flash it could be "jedec-flash,nor-flash,flash" or whatnot.
> (Btw: no comma's, but 0-chars in the actual properties!)

    The "compatible" prop (as well as "name") should define which driver to 
select according to spec. (the Generic Names spec. delegates this role solely 
to the "compatible" prop). While specifying the flash interface (JEDEC in this 
case) is indeed useful (however, the current 'platform_device' based 'physmap' 
implementation doesn't allow to pass the probe type to the driver), the prop 
in the form suggested doesn't really help with selecting the MTD map driver 
(without which you can't support a NOR flash). A reference to 'physmap' should 
still be present in the node in one or another form...

WBR, Sergei