Re: [RFC] Adding MTD to device tree

quoted

quoted

quoted

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

Not necessarily on all OSes.

quoted

quoted

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.

quoted

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.

quoted

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

Exact set of properties isn't defined anywhere.  "device_type" defines a
pretty generic interface, mostly saying what methods will be there (but
you don't care for that for a flattened tree); "compatible" communicates
to the OS what this device is exactly (so it can select a device driver
to use, for example).  "name" should not be used by anything but humans
normally.

quoted

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.

But memory devices aren't really block devices, for example, NOR-flash
is random access for everything but erase operations.

quoted

quoted

quoted

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

   This property might be marked optional still.

Then there's no reason to include it in the binding; "model" is
already defined in the base spec.

quoted

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

"compatible" denotes the device's specific programming interface,  
_not_ the
name of the device's driver in some random OS.  If you don't care for  
the
detailed interface (because your driver will probe for it itself for  
example,
as you said), you can take the next-less-specific entry from  
"compatible" and
use that instead.  Although it would be better to just probe for the few
specific interfaces defined (jedec-flash, cfi-flash, and a few more  
perhaps).


Segher