OF compatible MTD platform RAM driver ?

Segher Boessenkool segher at kernel.crashing.org
Sun Mar 30 18:39:21 EDT 2008


>>> For RAMs we
>>> need something to indicate that it's memory but intended for 
>>> secondary
>>> storage, not as main memory.
>>
>> How it is intended to be used is not a property of the hardware, so
>> that information doesn't belong in the device tree at all.  The Linux
>> platform code should handle this, I imagine.
>
> There must be some reason why it is not intended to be used as main
> memory.  Presumably it has something different about it compared to
> "normal" RAM, and that difference could perfectly well be expressed in
> the device tree.

Sure, that's a different thing.  It might sit on a bus that doesn't
do cache coherency, or maybe it's just slow (or sits on a slow bus).
All these things can be usefully expressed in the device tree (but
typically are not, it is left to the client code to know this stuff
implicitly).

It's still the (platform) probe code its responsibility to figure
out what (if anything) to do with any device.  And "main memory"
is probed differently (via /chosen/memory, for example) anyway.
Well, actually, Linux searches for all nodes with device_type "memory",
which should work fine as well [*].

So, all in all, I think we should just give these "auxiliary memory"
devices a name of "ram" c.q. "rom", and some "reg", and that should
be all that is needed: the main memory probe stuff won't consider
these nodes, and the (platform) device probe code can do whatever it
wants (create mtd devices, I guess).


Segher


[*] It seems to me the longtrail workaround code in prom_init.c is
incorrect though: it will match any node with name "memory" that
doesn't have a device_type?




More information about the linux-mtd mailing list